|
|
Log in / Subscribe / Register

Has Bionic stepped over the GPL line?

By Jake Edge
March 20, 2011

Way back in the early days of Linux, shortly after Linus Torvalds switched the kernel from his own "non-commercial" license to the GPL, he also added an important clarification to the kernel's license. In the COPYING file at the top of the kernel tree since mid-1993, there has been a clear statement that Torvalds, at least, does not consider user-space programs to be derived from the kernel, and thus are not subject to the kernel's license:

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".

One could easily argue that this distinction is one of the reasons that Linux is so popular today as programs written to run on Linux can be under whatever license that the developer chooses. Some recent analyses of Google's Bionic libc implementation, which claim that Google may be violating the kernel's license, seem to be missing—or misunderstanding—that clarification.

A blog posting from Raymond T. Nimmer, who is a professor specializing in intellectual property (IP) law, was the starting point. That posting looks at the boundaries between copyleft and non-copyleft code. Nimmer specifically analyzes the question of whether header files that specify an API to a GPL-covered work can be incorporated into a program that is not released under the GPL. He points to Google's use of the kernel header files in the Bionic library as an example and concludes:

For entities that do not desire to disclose code or force their customers to do so, or otherwise conform to copyleft obligations, working with copyleft platforms and programs presents a very significant and uncertain, risk-reward equation.

Nimmer's post was noticed by Edward J. Naughton, a practicing IP attorney, who then wrote briefly about it at the Huffington Post. Naughton also did a much longer analysis [PDF] as an advisory for his law firm, Brown Rudnick. That advisory concludes with a fairly ominous warning:

But if Google is right, if it has succeeded in removing all copyrightable material from the Linux kernel headers, then it has unlocked the Linux kernel from the restrictions of GPLv2. Google can now use the "clean" Bionic headers to create a non-GPL'd fork of the Linux kernel, one that can be extended under proprietary license terms. Even if Google does not do this itself, it has enabled others to do so. It also has provided a useful roadmap for those who might want to do the same thing with other GPLv2-licensed programs, such as databases.

In turn, Naughton and Nimmer's analyses were picked up by Florian Mueller who wrote a blog post about the serious threat that Google and Android face because of this supposed GPL violation. So, is Google really circumventing the GPL in a way that could threaten Linux? To answer that, we'll have to dig into what Bionic is, how it is built, and whether it violates the letter or spirit of the Linux COPYING file.

An interface for user space

The kernel exists to provide services to user space, and one can do nothing useful from user space on a Linux system without invoking the kernel via a system call. That system call boundary is quite clear. It requires a special instruction that puts the CPU into kernel mode in order to invoke one. While programmers may see system calls as simple library calls, that's not what's happening under the covers.

In order to use Linux system calls, though, it is necessary to get information from the kernel header files. Various pieces of information are needed including system call numbers (which is how they are invoked), type information for various system call arguments, as well as constants that are required to properly invoke those calls. That information is stored in the kernel headers and any program that wants to run on Linux needs to get that information somehow.

The most common way to invoke the kernel is by using GNU libc (glibc). Glibc has a set of "sanitized" kernel header files that are used to build the library, and distributions typically provide packages with those header files to be installed into /usr/include. Programs can then be built by using those header files and linking to glibc. While "sanitized" may sound like it refers to the removal of GPL-covered elements from those files, the main reason it is done is to remove kernel-specific elements from the files. The kernel headers have lots of kernel-internal types, constants, and functions that are not part of the kernel interface.

It isn't really correct to call the interface that the kernel provides to user space an API (i.e. application programming interface), as it is really an application binary interface (ABI), and one that the kernel hackers strive to maintain for each new kernel release. Removing something from the kernel ABI almost never happens, though new features expand that ABI frequently. The ABI is what allows binaries that were built on an earlier kernel to run on newer kernels. The API, on the other hand, is provided by glibc or some other library.

Using glibc is just one way for a program to be built to run on Linux. There are other libc implementations, including uClibc and dietlibc, which are targeted at embedded devices, as well as the embedded fork of glibc, EGLIBC. A program could also use assembly language instructions to make system calls more directly. Using any of those methods to get at the system call interface is perfectly reasonable, and will require information from the kernel headers. Glibc may be the most popular, but it certainly isn't the only way.

Android's Bionic libc is, at some level, just another alternative C library implementation. It is based on libc from the BSDs with some Google additions like a simple pthread implementation, and has a BSD license. It's also a lot smaller than glibc—roughly half the size. The license satisfies one of the goals for Android: keeping the GPL out of user space. While glibc is not under the GPL, as it is licensed under the LGPL (v2 currently, with a plan to move it to v3), that may concern Google (and its partners) because LGPLv3 requires that users be able to replace the library—something that doesn't mesh well with locking down phones and other Android devices. In the end, it doesn't matter, as Google, like any other kernel user, can make Linux system calls any way it chooses.

Bionic's use of kernel headers

So what does Google do that causes Nimmer, Naughton, and Mueller to claim that it is circumventing the GPL to the detriment of the community? To create the header files used by Bionic, and applications, Google processes the kernel header files to remove all of the extra stuff that is either only there for the kernel, or doesn't make sense in the Bionic environment. In short, with minor exceptions, Bionic is doing exactly what glibc is doing, taking the kernel header files and massaging them into a form that defines the interface so that they can be used by the library itself and any applications that use the library. Nor has Google hidden what it's done, as there is a README.TXT file that is quite clear on what it is doing and why it is doing it.

Glibc and others may be using the kernel headers that can be generated from a kernel source tree by doing a "make headers_install". That Makefile target was added to help library developers and distributions create the header files that are required to use the kernel ABI. It is not a requirement, as there are other ways to generate (or create) the required headers, and various libraries have done it differently along the way. The Android developers intend to eventually use the headers that can be created from the kernel tree, but there are currently some technical barriers to doing so. The key piece to understand is that the information required to use the kernel ABI are contained in one and only one place: the kernel header files.

There are two things that Bionic does that are perhaps a bit questionable. The first is that as part of munging the header files, it removes the comments from them, including the copyright notice at the top of the file. It replaces the copyright information with a generic "This header was automatically generated ..." message, which concludes with: "It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information." The latter part is likely what has the IP experts up in arms. Much of Naughton and Nimmer's postings indicate that they believe Google overreached in terms of copyright law by stating that the files do not contain elements eligible for copyright protection.

They may be right in a technical sense, but it still may not make any difference at all. Calling into the kernel requires constants and types (structures mostly) that can only come from the kernel headers. Those make up the functional definition of the ABI, and that ABI has been explicitly cleared for use by non-GPL code. One could argue that Google should keep the copyright information intact—one would guess lawyers were involved in the decision not to and the wording of that statement—but that is most likely only a nicety and not required once one understands that those files just contain the ABI information, nothing more.

Well, perhaps there is a bit more. The Bionic README, notes that "the 'clean headers' only contain type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)". The latter might be considered elements worthy of copyright protection—and not part of the kernel ABI—but they might not as well. Those routines are written in assembly code, so they might well be considered to be the only way to efficiently write byte-swapping routines for each of the architectures and thus might be considered purely functional elements.

Misunderstanding Torvalds

Both Naughton and Mueller make a big deal about a posting from Torvalds in 2003 that ends with the shout: "BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES." While it would seem to be a statement from Torvalds damning exactly what Google is doing, that would be a misreading of what he is saying. One need look no further than the subject of the thread ("Linux GPL and binary module exception clause?") to see that the context is not about user-space binaries, but instead about binary kernel modules. Torvalds may have been a little loose with his terminology in that post, but stepping back through the thread makes it clear he is talking about kernel modules. Furthermore, in another post in that same thread, he reiterates his stance on user-space programs:

This was indeed one of the worries that people had a long time ago, and is one (but only one) of the reasons for the addition of the clarification to the COPYING file for the kernel.

So I agree with you from a technical standpoint, and I claim that the clarification in COPYING about user space usage through normal system calls covers that special case.

But at the same time I do want to say that I discourage use of the kernel header files for user programs for _other_ reasons (ie for the last 8 years or so, the suggestion has been to have a separate copy of the header files for the user space library). But that's due to technical issues (since I think the language of the COPYING file takes care of all copyright issues): trying to avoid version dependencies.

That's a pretty unambiguous statement about using the kernel headers for user-space programs. In fact, in the early days, the accepted practice was to symbolically link the kernel headers into /usr/include, and one might guess that any number of proprietary (and other non-GPL) programs were built that way. Torvalds is no lawyer (nor am I), but his (and the other kernel hackers') intent is likely to be very important in the extremely unlikely case this ever gets litigated.

It is almost amusing that Mueller argues that Google should switch to using glibc, rather than Bionic. It reflects a grave misunderstanding of the differences between the two libraries. If the Nimmer/Naughton arguments are right, it's hard to see how glibc is any different. Their argument essentially boils down to there being no way to use the kernel headers without a requirement to apply the GPL to the resulting code.

It's certainly not impossible to imagine someone filing a lawsuit over Android's use of the kernel headers. It's also possible that a judge might rule against Android. But given that kernel hackers want user-space programs to use the ABI and that the COPYING file explicitly excludes those programs from being considered derived works of the kernel, one would guess that some kind of workaround would be found rather quickly. Other than the fear, uncertainty, and doubt that these arguments might engender, one would guess that Google isn't really losing much sleep over them.

to post comments

Naughton didn't do enough research to justify his conclusions.

Posted Mar 20, 2011 22:13 UTC (Sun) by bkuhn (subscriber, #58642) [Link] (36 responses)

I wrote a blog post pointing out that Naughton lengthy analysis is actually quite shoddy, and he hasn't engaged in the detailed research that would be needed to justify the claims that have been made.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 5:05 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (34 responses)

1) I never thought that Naughton's paper claimed to know the answer. It was, just the way you see it, meant to ask an important question: is this a legally safe approach or are there risks that go beyond what's acceptable? And what's acceptable depends, as I point out in my blog post, on how much is at stake. For the C library of a platform on which an entire mobile ecosystem is built, there must undoubtedly be a more cautious and conservative approach than to, say, a device driver that affects only a single vendor, or to a single third-party application.

2) So when you claim that "he hasn't engaged in the detailed research that would be needed to justify the claims that have been made", I believe that someone highlighting a need -- in light of what I said in the previous paragraph -- to take a closer look at something doesn't have to meet the detailed research standard you would expect in court, or if he claimed with certainty that there is an infringement. So far I haven't seen any other expert claim that there isn't an infringement: you admit in your blog post that there may be one; Eben Moglen was evasive when ZDNet's SJVN asked; LWN's article above doesn't rule out the possibility.

3) There are good reasons to raise the question whether you, @bkuhn, engaged in even the non-detailed research that would have been necessary to make the claims you made. I don't think so in a couple of cases:

3.1) You claim that "Google wasn't seeking to circumvent the GPL at all." The LWN article above tells a different story. In my blog post, I link to this official Android architecture presentation, on page 36 of which you can find, in the specific context of Bionic, the stated goal: "keep GPL out of user-space [sic]"

3.2) You also seem to be placing bets without sufficient research: "If someone actually does all the research to prove that Google did, I'd easily offer a 1,000-to-1 bet to anyone that such a copyright infringement could be cleared up easily [...]"

This flies in the face of everything I know about this industry after 25 years of work, during which I've had discussions on possible alterations of large codebases with CEOs, CTOs and VPs of Engineering on numerous occasions, often with those of major software publishers such as Blizzard Entertainment (I edited, although my focus at the time was on the commercial side, a small part of the Warcraft II C sources myself). During all of that time, I never came across an engineering decision-maker who made your 1,000-to-1-bet claim concerning any (even the slightest) change to a large codebase. Everyone who really knows how it works will tell you that once you make such changes -- and replacing a C library is pretty significant anyway, but let's assume you're right and it's small -- you run the risk of destabilizing parts of a large codebase where you didn't even expect it. With a "release early, release often" mentality one can just replace such a library without caring much; but I doubt that the likes of Samsung and Motorola want to "release early, release often" their devices.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 6:11 UTC (Mon) by rsidd (subscriber, #2582) [Link] (18 responses)

"So far I haven't seen any other expert claim that there isn't an infringement"

This sounds about as convincing as "So far I haven't seen any other expert claim that you do not beat your wife." Unless the wife in that statement, or a supposedly infringed party in your statement, speaks up, there is no point talking about it.

Sorry, Florian, it is you who sound vague and unclear. You're throwing muck randomly, hoping that something will stick.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 6:18 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (17 responses)

Sorry, @rsidd, you just quote very selectively. You cut off your quote right before "you [@bkuhn] admit in your blog post that there may be [an infringement]; Eben Moglen was evasive when ZDNet's SJVN asked; LWN's article above doesn't rule out the possibility." (So some people who should know did issue statements, but they are apparently unsure.)

Your analogy with the beaten wife (maybe could have come up with a less bizarre example anyway) doesn't work. Your position is that until someone with standing acts, "there is no point talking about it". I don't know in which world you operate but that position is neither in line with FOSS community values nor with (which is what my focus here is) the way the world of business operates.

From a FOSS point of view, if something is done that goes against principles that should be defended, then it's wrong and must be called out not only when someone goes to court.

From a business point of view, if a device maker or developer of a major app spends millions of dollars -- possibly MANY millions of dollars --, there has to be a degree of legal certainty that's reasonable under such circumstances. The possibility of any one out of thousands of Linux kernel contributors possibly going to court in some major jurisdiction is an issue to take into consideration before it happens.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 9:36 UTC (Mon) by foom (subscriber, #14868) [Link] (15 responses)

> From a FOSS point of view, if something is done that goes against principles that should be defended, then it's wrong and must be called out not only when someone goes to court.

Creating a brand new libc that's not under the GPL *doesn't* go against principles. That it needs to use the linux syscalls is completely obvious, and even explicitly stated as permitted (in case anyone had any doubts).

The only question is whether in a technical legalistic sense, they erred in their implementation. Making a big fuss of that seems to me is just blowing smoke.

BTW, RMS had this to say about it (from 2003):
http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/036...

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 10:47 UTC (Mon) by rvfh (guest, #31018) [Link]

Thanks, I think this completes the article nicely.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 10:49 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (13 responses)

Are you saying that taking files with original copyright and GPL notices and cutting out those notices is just fine and in the spirit of the GPL?

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 11:41 UTC (Mon) by dgm (subscriber, #49227) [Link] (12 responses)

Florian, what are you trying to do?

1. we are not talking about random code files, but a very special case.
2. it has become apparent that the elements copied are NOT subject to copyright.
3. It's fine and in the spirit of what the authors meant, and probably the GPL too, but the first part should be more than enough.

Your position is very, very weak. You can only argue about legal subtleties, and even there you're not in firm ground. Why do you insist in spreading the FUD?

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 11:48 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (11 responses)

1. we are not talking about random code files, but a very special case.

How will you separate this special case from other cases of copyright laundering? Are you sure Google hasn't already done this in other cases, too?Are you sure nobody else has done or will now consider doing this, following Google's example?

2. it has become apparent that the elements copied are NOT subject to copyright.

How come that neither Eben Moglen in his answer to ZDNet nor Brad Kuhn in his blog post nor LWN (on this very page) rule out the possibility of an infringement? Apparently what you think is not apparent.

3. It's fine and in the spirit of what the authors meant, and probably the GPL too, but the first part should be more than enough.

This is a totally unsupported claim of yours.

Your position is very, very weak. You can only argue about legal subtleties, and even there you're not in firm ground.

Unfortunately, such "legal subtleties" can be outcome-determinative. I don't claim that I know 100% for sure that there is an infringement. I read Edward Naughton's paper and I think he has a reasonable basis for raising concerns. I'd love to see Google take care of those concerns by replacing those headers with glibc.

Why do you insist in spreading the FUD?

The word FUD is wrong here for various reasons. I'll name two. One, as the aforementioned, non-committal positions by Eben Moglen, Brad Kuhn and LWN show, there is a lack of certainty out there. So it's not like FUD in the sense of artificially creating or suggesting uncertainty. Two, I don't say that this is the end of Android. I believe a fix is doable, and it's imperative. The sooner it's done, the better. The easier it is to do, the better. But it must be done.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 12:01 UTC (Mon) by rsidd (subscriber, #2582) [Link] (8 responses)

FUD is exactly what you are doing. Why are Eben Moglen, Brad Kuhn and LWN not saying categorically that there is no infringement? Because they cannot say so without auditing 2.5 MB of headers. All they can say is that there are no reasonable grounds to suspect a problem -- which is what they are saying. Can I stand on a soapbox and claim that Linux has a problem because nobody in the world will categorically assert that its code does not violate any copyrights, trademarks or patents held by others? Nobody, certainly not the kernel developers, will ever assert that. All anyone can reasonably do is fix problems once they are alerted. Problems may exist with bionic and copyright infringement -- no sane person will categorically deny that possibility. But you, sir, have not demonstrated ANY problem that needs fixing. The "problems" you have pointed out have been debunked, and you are reduced to saying "but there may be other problems!" You cannot expect Moglen, Kuhn or LWN to do that dirty work for you.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 12:05 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (7 responses)

Why are Eben Moglen, Brad Kuhn and LWN not saying categorically that there is no infringement? Because they cannot say so without auditing 2.5 MB of headers. All they can say is that there are no reasonable grounds to suspect a problem -- which is what they are saying.

No, they don't say there are no reasonable gorunds to suspect an infringement. Brad Kuhn and LWN explicitly admit the possibility of a copyright infringement. Eben Moglen tried to beat around the bush.

All anyone can reasonably do is fix problems once they are alerted. [...] But you, sir, have not demonstrated ANY problem that needs fixing

I believe the Naughton paper provides indications that there is a need for fixing. Have you even read it in its entirety? I mean the paper, not just the Huffington Post article?

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 14:33 UTC (Mon) by drag (guest, #31333) [Link] (6 responses)

If you were a lawyer you'd realize there is no such thing as 'black and white' in laws like this. Everything is up for interpretation. It's extremely difficult to say for certain.

It's very unlikely that it's really a infringement issue.

In reality is that unless one of the copyright owners actually gives a crap about bionic using the header files then the entire issue is completely irrelevant.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 14:43 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (5 responses)

I don't need legal education from you, @drag. Of course there's no black and white. However, while you say "[i]t's very unlikely that it's really a [sic] infringement issue", they say there may be one, and LWN and Brad Kuhn talk about what they consider an easy fix, which is an admission in and of itself.

While you say it's irrelevant until someone sues, you can be sure that there are defenders of the copyleft principle who think that potential and actual violations are an issue all by themselves, and more importantly, the way you argue is not the way corporate decision makers in the ecosystem can afford to look at such matters.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 15:53 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

I really couldn't give a shit about copyleft in this case.

The only people that have any rights in this case are the copyright holders. I am certainly not going to care more then the people that wrote the code.

And the way I argue is expressing the reality of the situation. If 'corporate decision makers' want to look at it differently they are being delusional.

Nobody can know for certain, mistakes happens. Shit happens constantly. Then problems are fixed.

People believing in pseudo-legalistic bullshit and making big issues out of non-issues is a severe problem. It needs to be nipped in the bud as all it generates is useless drama and bad feelings.

> they say there may be one

The fact that you can keep saying shit like this with a straight face shows that you understand far less then you think you do. Either that or your being intentionally obtuse.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 19:48 UTC (Mon) by foom (subscriber, #14868) [Link]

> People believing in pseudo-legalistic bullshit and making big issues out of non-issues is a severe problem. It needs to be nipped in the bud as all it generates is useless drama and bad feelings.

+1. ISTM Florian seems to be making a really bad habit out of this. I wanted to give him the benefit of the doubt for a long time, but come on...

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 18:24 UTC (Mon) by rahvin (guest, #16953) [Link] (2 responses)

I don't need legal education from you, @drag. Of course there's no black and white. However, while you say "[i]t's very unlikely that it's really a [sic] infringement issue", they say there may be one, and LWN and Brad Kuhn talk about what they consider an easy fix, which is an admission in and of itself.
You need a legal education from someone if you are going to spout off about legal matters and sow FUD in the community. Unless they are providing legal counsel their response is the one required or they will fall afoul of the US Bar and could be liable if their "advice" turns out incorrect. That's legal 101. I doubt the FSF has even bothered to review the issue as they haven't been asked to by the copyright holders so they result to the typical non-committal lawyer speech when they can't answer a question. Finally, suggesting a fix doesn't mean there is a problem. The fix could be to eliminate concern or it could simply be to eliminate FUD or even just be suggestion without merit.
While you say it's irrelevant until someone sues, you can be sure that there are defenders of the copyleft principle who think that potential and actual violations are an issue all by themselves, and more importantly, the way you argue is not the way corporate decision makers in the ecosystem can afford to look at such matters.
Unless the copyright holders wish to take action then it doesn't matter what anyone in the community thinks. It's not their concern because they can't legally take action. The kernel has always included the user space exception since very very early on. You've been spreading FUD. Why don't you tell everyone why you are so concerned about this issue that you have run around on a press gauntlet screaming about how dangerous Android is to use? Explain your motives and maybe people will take you more seriously. Because there is a significant percentage of the community that thinks you are whoring FUD for your current employer. So what is your motivation in this?

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 18:29 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

When did Brad Kuhn become a member of the Bar? The answer: never. And Jake Edge? I don't see any indication he's admitted as an attorney at law. Therefore, you can't claim they're limited in expressing their opinions. @rahvin, your post is generally unreasonable and doesn't contribute anything of substance to the discussion.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 27, 2011 0:43 UTC (Sun) by malor (guest, #2973) [Link]

Florian, you are just being freaking ridiculous here. You have yet to state an actual cause for action, but you post again and again and AGAIN, in every Android thread, screaming about possible infringement. I mean, you've actually used the term 'copyright laundering' with a straight face.

Here's the deal. If you think there's infringement, prove that there's infringement. It'll take a hell of a lot of work. But that's the ONLY basis from which you can be making those kinds of claims

Your current claim seems to amount to this: certain specific people aren't stating with absolute certainty that there's no infringement. Therefore, there must be infringement. This is stupid.

  1. They don't want to do all that digging in header files they didn't author; they don't want to do the work any more than you do.
  2. Even if they did all that work, and then registered the strong opinion that there was no infringement, it wouldn't matter, because they don't have standing to make that determination.
  3. Only the people who wrote the headers can make an infringement claim. And if they don't care, if they've released the headers under a permissive license, then there is no issue. Only their opinion is important. Bradley Kuhn's and Jake Edge's are entirely irrelevant.
  4. Yet, you insist on screaming that because unrelated people without legal standing won't put many hours of work into analyzing headers, that means Android is untrustworthy.
This is called "pushing an agenda", Florian. You look like a paid astroturfer to me.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 12:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>How will you separate this special case from other cases of copyright laundering?

By applying laws. Technical interfaces are not copyrightable.

>Are you sure Google hasn't already done this in other cases, too?Are you sure nobody else has done or will now consider doing this, following Google's example?

So what? Use only of structure definitions from include files is totally OK.

BTW, MinGW and Cygwin both do this for their "windows.h" file.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 24, 2011 5:22 UTC (Thu) by jtc (guest, #6246) [Link]

It seems to me that one of the main points of misunderstanding in this issue is this quote from the LWN article of what Naughton supposedly said in his advisory:

"But if Google is right, if it has succeeded in removing all copyrightable material from the Linux kernel headers, then it has unlocked the Linux kernel from the restrictions of GPLv2. Google can now use the "clean" Bionic headers to create a non-GPL'd fork of the Linux kernel, one that can be extended under proprietary license terms...."

How does using kernel headers in user-space binaries (bionic) (which is allowed according to the quoted statements from Linus) imply that it is legal (allowed by the license) to use kernel headers to produce a non-GPL fork of the Linux kernel (which is not user-space, but kernel space)? I think the answer is "There is no such implication."

It seems to me that making a sound judgement on this issue requires both legal and technical expertise. The quote of Naughton's appears to indicate that he may have sound legal expertise, but he does not at all appear to have sound technical expertise, nor to have a sound technical consultant at his disposal.

The result appears to be a bogus argument based on a technical misunderstanding.

Naughton didn't do enough research to justify his conclusions.

Posted Apr 6, 2011 19:32 UTC (Wed) by krakensden (guest, #72039) [Link]

> Your analogy with the beaten wife (maybe could have come up with a less bizarre example anyway) doesn't work

He's referencing a famous explanation of 'poisoning the well', a rhetorical strategy.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 9:20 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

"keep GPL out of user-space" doesn't sound like circumvention to me. "Find a legalistic hack that lets us provide userspace stuff based on GPL without creating GPL exposure for third-party userspace developers" would be circumvention.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 14:36 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (3 responses)

Re 1: It is a question, sure; but important it isn't. For more than a decade all sorts of propietary programs have used glibc and run under Linux, nobody ever complained about it.

Re 2: While there isn't detailed research pointing one way or the other, the (limited) evidence available seems to indicate the point is moot. Also, the relevant people have explicitly stated several times what they mean by the license, see e.g. Linus on what he deems covered by GPL, see also Richard Stallman's view on header files. This surely clarifies any remaining murkiness (thanks to Groklaw's news pick for the references).

Re 3.1: Sorry, but "keep GPL out of userspace" (legally!) isn't the same as "circumventing GPL"

Re 3.2: I'd bet the same way than he does, sorry. The intent of the kernel folks is precisely that the GPL doesn't cross over to userland, so if/when some real problem is found here they'll work on straigtening it out.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 14:52 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (2 responses)

Re 1) I'm not complaining -- but instead advocating -- glibc in this context. Since glibc has a genesis that is fundamentally different from that of Bionic, you can't infer anything from the fact that glibc is legally safe according to industry understanding. We wouldn't be having this discussion if Bionic used glibc, or a similar library derived from the sanitized headers.

It seems @vonbrand that you don't fully understand the genesis of the sanitized headers, so please educate yourself before you confuse people here. Again, I'm all for glibc, but Bionic is a very different animal.

Re 2) What Linus Torvalds and RMS said is not related to Bionic and doesn't answer any of the legal questions at issue here.

Re 3.1) You conflate Google's objective with the legality of its chosen means in a way that distorts what I said. The objective clearly was to work around, or "circumvent", the GPL. TheFreeDictionary defines "to circumvent" in this context as "to go around; bypass; avoid or get around by artful maneuvering." So it can be legal or illegal. In that nonjudgmental sense, there's no doubt Google sought to circumvent the GPL, and the use of a script to cut out parts of approximately 750 header files to declare the remainder (which is actually the essence of those files) non-copyrightable is at least "artful".

Re 3.2) Your bet just shows that you're unlike the decision makers at commercial software companies (or hardware and other companies that build software for commercial purposes). His bet is meaningless -- and so is your support of it -- because real decision makers will take a different perspective and Google will only convince them by actually delivering a fix, not by saying it's easy to deliver one if and when needed.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 16:35 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (1 responses)

Re 1: Google doesn't want glibc, they wrote their own. Perfectly allowed. There never has been a requirement to use glibc (Yes, I was around when it was adopted). If they start with the headers sprinkled with holy penguin pee by doing "make install_headers" or the raw ones is something easy to fix, and probably not enough of a difference to do any harm.

Re 2: Linus and RMS are talking explicitly about this exact point in the emails I link. Their intent surely means something here... if somebody came out of the woods and claimed their lines in *.h were meant only for use in GPLed code, the above, unambiguous, statements to the contrary (which as a contributor to the kernel everybody is aware of) would surely get them into big trouble.

Re 3.1: OK, if it is called "circumvent the GPL" or not isn't the point. The point is that what they are doing is exactly in line with what the copyright holders intended (and stated very explicitly). If something is being done "artfully" (skillfully, clever) or plain bluntly is besides the point here.

Re 3.2: My bet is mine, and mine only. Yes, extremely paranoid decision makers might shy away because of this brouhaha, but I daresay they won't take decisions for long if they insist in such views... there are certainly much more tangible risks in all sort of routine activities.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 24, 2011 5:27 UTC (Thu) by jtc (guest, #6246) [Link]

"Re 2: Linus and RMS are talking explicitly about this exact point in the emails I link. Their intent surely means something here... if somebody came out of the woods and claimed their lines in *.h were meant only for use in GPLed code, the above, unambiguous, statements to the contrary (which as a contributor to the kernel everybody is aware of) would surely get them into big trouble."

In other words, this quote, above, is 100% incorrect:

"Re 2) What Linus Torvalds and RMS said is not related to Bionic and doesn't answer any of the legal questions at issue here."

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 15:41 UTC (Mon) by jubal (guest, #67202) [Link] (7 responses)

Mr. Mueller,

Could you state explicitely, that you're have not been and are not currently being paid 1) by any of the companies being Google's competitors and 2) to work on PR stuff related to Google Android? Just to make things clear once and for all.

Thank you in advance,

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 16:06 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (5 responses)

I don't know who you are and who you work for, so you're not being nearly as transparent as I am by using my real name here. And you're off-topic. On my blog and in discussions like I express exclusively my own beliefs, and that's all I have to say about that. Now let's get back to the actual issues. Conspiracy theories are weak and pointless, especially when they're baseless like in this case.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 16:19 UTC (Mon) by jubal (guest, #67202) [Link]

Thank you for answering my question in such a clear and concise manner.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 18:41 UTC (Mon) by jonquark (guest, #45554) [Link]

I don't think whether you are paid to campaign on this issue (or against Android in general) is off-topic. Could you just confirm that you are receiving no remuneration in connection with consultation/lobbying on Android or against Google.

If you think it's relevant despite me expressing no other opinion on this issue so far: my full legal name is Jonathan Levell. My homepage is http://www.coralbark.net/ . I am employed by IBM as a software engineer (writing closed-source middleware unconnected to this issue) but I write this comment purely in a personal capacity. I am not authorised to speak on this issue (or pretty much any other ;) by my employer and certainly do not represent them here.

A short (clear) comment from you would be both on-topic and illuminating.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 21:28 UTC (Mon) by mdakin (guest, #42701) [Link]

But you did not answer his question.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 23:37 UTC (Mon) by clump (subscriber, #27801) [Link]

I don't know who you are and who you work for, so you're not being nearly as transparent as I am by using my real name here.
You've not disclosed any conflicts of interest. Jubal has been more transparent in this discussion.
And you're off-topic.
Because you link incessantly to your blog, you are in fact inserting yourself and your opinions in the discussion. Your conflicts of interest are therefore relevant.
Now let's get back to the actual issues. Conspiracy theories are weak and pointless, especially when they're baseless like in this case.
The actual issue is still your failure to disclose conflicts of interest, or the lack of conflicts of interest.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 22, 2011 3:55 UTC (Tue) by rsidd (subscriber, #2582) [Link]

Florian - thanks for that comment. I'm bookmarking it, to remind myself (and perhaps others) where you stand on disclosures of conflicts of interest. (Hint: "off-topic" won't cut it with an editor of a scholarly journal, a respectable newspaper, or, for that matter, LWN.net. With scholarly journals, in particular, failure to disclose conflicts of interest is viewed as a serious ethical breach.)

Naughton didn't do enough research to justify his conclusions.

Posted Mar 22, 2011 12:01 UTC (Tue) by michel (guest, #10186) [Link]

Pretty funny how Mr. Mueller disappeared from here right after that non-answer while prior to that he pretty much immediately answered any post with his name in it. Of course, that could be a coincidence but it amuses me.

I'd say we pose the same question immediately any time he shows back up here with his comments. If it makes him disappear, I for think that it would improve the overall quality of the conversation. But if not, perhaps we'll actually get that answer at some point.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 19:26 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Excuse me, ripping out and replacing a libc is certainly something I'd not bet on for any largeish codebase. But we are talking about selecting a libc (or deciding to write our own). In which case, if I had any slight doubt of legality of using a LGPLv2.1 libc (and the considering the possibility that it'd move to LGPLv3) I'd also consider writing my own. Exactly the type of risk analysis you propose, but the result is different.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 21, 2011 21:14 UTC (Mon) by clump (subscriber, #27801) [Link]

Again, I respectfully ask that you disclose any conflicts of interest.

Naughton didn't do enough research to justify his conclusions.

Posted Mar 22, 2011 11:26 UTC (Tue) by Seegras (guest, #20463) [Link]

He didn't need to, he's a Microsoft-shill. He's only spreading FUD.
http://webcache.googleusercontent.com/search?q=cache:ZB1R...
(Google cache, since the references to "Microsoft" have been replaced lately...)

Has Bionic stepped over the GPL line?

Posted Mar 20, 2011 22:29 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (4 responses)

Mueller is dead wrong in his analysis... if bionic can only be distributed under GPL due to its use of *.h files taken out of the kernel (after cleansing), then glibc must also, as it is doing the same (even with less cleansing of said files).

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 5:22 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (3 responses)

glibc uses "sanitized" headers made available by the kernel maintainers for integration into C libraries. Bionic, however, puts the original "raw" kernel headers through a scrubber script and repurposes them.

Also, if my analysis is "dead wrong", how come that neither Eben Moglen when asked by ZDNet nor Brad Kuhn in his blog post nor LWN in the above article say affirmatively that Bionic isn't copyright-infringing?

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 6:12 UTC (Mon) by jmm82 (guest, #59425) [Link]

This article disproved your article with a reference to the same Linus thread you misquoted out of reference. I will post it here in case you missed it.

On Fri, 5 Dec 2003, Kendall Bennett wrote:
>
> Right, and by extension of the same argument you cannot use kernel
> headers to create non-GPL'ed binaries that run IN USER SPACE!

This was indeed one of the worries that people had a long time ago, and is
one (but only one) of the reasons for the addition of the clarification to
the COPYING file for the kernel.

So I agree with you from a technical standpoint, and I claim that the
clarification in COPYING about user space usage through normal system
calls covers that special case.

But at the same time I do want to say that I discourage use of the kernel
header files for user programs for _other_ reasons (ie for the last 8
years or so, the suggestion has been to have a separate copy of the header
files for the user space library). But that's due to technical issues
(since I think the language of the COPYING file takes care of all
copyright issues): trying to avoid version dependencies.

Has Bionic stepped over the GPL line?

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

"Provided" headers mentioned by Florian are generated by a script - specifically, scripts/install_headers.pl. Which is to say, "remove sections under ifdef __KERNEL__, disable #warning in linux/types.h, strip annotations and some qualifiers, remove including of compiler.h".

AFAICS, they've done that unifdef - __KERNEL__-only sections are removed. If anything, they are stripping it harder than install_headers.pl does.

They might want to throw "known to be useless for userland" headers, excluded by make headers_install. Because any userland code that changes behaviour from exclusion of those headers is severely broken and they want to catch that anyway.

IOW, if all that stench amounts to "they are not using the headers provided by kernel for libcs", they can trivially switch to feeding results of make headers_install to their script, thus excluding the same files and reducing namespace pollution. At which point it's down to "they updated their libc, be very afraid!" Pathetic.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 14:55 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Surely the kernel headers sanitized for glibc's use are enough for bionic's similarly limited needs? Do you know for sure Google didn't start with said "cleaned for libc" headers?

Has Bionic stepped over the GPL line?

Posted Mar 20, 2011 22:55 UTC (Sun) by jmm82 (guest, #59425) [Link] (16 responses)

"It's certainly not impossible to imagine someone filing a lawsuit over Android's use of the kernel headers"

What is required for someone to have authority to bring google to court on a kernel violation? Who can file a lawsuit, anyone who has committed code to the kernel?

Has Bionic stepped over the GPL line?

Posted Mar 20, 2011 23:03 UTC (Sun) by jake (editor, #205) [Link] (15 responses)

> Who can file a lawsuit, anyone who has committed code to the kernel?

It's an interesting question. For this particular issue, my guess would be that they would need a copyright on some part of the kernel header files that are used in Bionic. Writing a random device driver, for example, would seem to lack the proper standing. Actually, of course, all of that is incorrect, anyone could *file* a lawsuit (even with no kernel copyright, I suppose), but to have a reasonable standing to make any progress, I would think you would have to have copyrights that are directly involved. IANAL of course.

jake

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 0:42 UTC (Mon) by jmm82 (guest, #59425) [Link] (14 responses)

Thank you for the response. I am glad to see a clear written article on this topic. Here is the closest I could find to an answer from the gpl FAQ

"Who has the power to enforce the GPL?
Since the GPL is a copyright license, the copyright holders of the software are the ones who have the power to enforce the GPL. If you see a violation of the GPL, you should inform the developers of the GPL-covered software involved. They either are the copyright holders, or are connected with the copyright holders. Learn more about reporting GPL violations."

I think your response is reasonable, but if I recall correctly, the Linux kernel does not have any form of copyright assignment and therefore all contributors per se are copyright holders.

The real question I guess I was really thinking was have any kernel developers voiced concerns in this topic or is this just lawyer bloggers trying to create something out of nothing?

I can honestly say I have meet misinformed people who read these headlines in the news and are worried to buy android phones out of fear of breaking the law. This is really sad.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 1:45 UTC (Mon) by corbet (editor, #1) [Link] (4 responses)

I have yet to encounter a kernel developer who is concerned about the use of header files in bionic. That does not mean that no such developers exist, of course, but I suspect they are relatively rare.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 5:33 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (2 responses)

Since it only takes one out of thousands of contributors to cause a problem (provided that he has standing, but he could find a jurisdiction that suits him for that purpose), it isn't reassuring for the ecosystem that there may be thousands of other contributors who don't care. Those thousands of other contributors could all tell the court that they're fine with this, and the court would still have to decide one contributor's complaint on the basis of its merits.

This is again the question I already mentioned in my reply to @bkuhn above: what degree of legal certainty is reasonably required when we're talking about a platform on which an entire ecosystem is built? (as opposed to a device driver affecting only a single vendor, or a component of a single third-party app)

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 18:33 UTC (Mon) by rahvin (guest, #16953) [Link] (1 responses)

NOT thousands of contributers. The only ones with copyright in the headers are the ones who WROTE the headers. That's it. Some random developer who has a small piece of code in the kernel has no copyright on the headers. That is if the headers even have copyright. Much like the SCO case the headers could be considered API/ABI and be completely fact and devoid of copyright. There is substantial case law to support that conclusion in the US.

Has Bionic stepped over the GPL line?

Posted Apr 2, 2011 5:54 UTC (Sat) by Duncan (guest, #6647) [Link]

Note that I'm neither a lawyer nor a kernel dev. If you're trying to use my posts as legal justification for anything contextually related without getting the opinion of professionals in at least one of those fields, your nuts!

Yours is the first post I've seen to bring out the important SCO headers point. Linux itself is dependent on the principle of headers being factual/technical presentations of the ABI and thus uncopyrightable as such. After all, Unix (R) Signal numbers, etc, as used by Linux, come from such headers. But there's quite some case history establishing such headers as interface facts, not copyrightable at least in the US.

In fact, at least within the US, the principle goes further as well. Independent reimplementations done specifically for interoperability with the public interface as customarily expressed in the headers are generally specifically allowed as well. Again, that's (part of) what let Linux off the hook in terms of the Unix (R) signal interface and (one of) the reason(s) that code couldn't be properly held as evidence of infringement. (Another was the fact that said signal interface code had been published in a public context in sources predating either SCO or Linux, said sources likely being the common source for both, thus SCO's confusion when they appeared to be duplicates.) As such, yes, the kernel headers as BOTH Google Bionic and glibc use them COULD be used as a basis for an independent kernel reimplementation. Without an audit it's certainly possible that a few trivial violations could leak thru, and that's actually what I expect all the experts that FM is pointing at are allowing for -- they've not done that audit and aren't under retainer to do it or to make a legally valid opinion as representing anyone, so they're allowing themselves the typical out that even debaters quickly learn -- don't make all inclusive statements without some out, some qualifier, if one hasn't actually done the work necessary to ensure no trivial logic leak, since an all-inclusive statement without qualifier is disproved with the most trivial possible exception.

But the point is, Google's sufficiently GPL averse to have avoided the Linux kernel and chosen a BSD implementation, or written or bought their own from elsewhere, if the Linux kernel itself didn't have SOME overriding value. That they chose Linux in spite of their otherwise GPL aversion demonstrates the value they consider it to have. Reimplementation? Perhaps, if you've got a couple billion dollars to pour down a rat hole. And why would they do that, starting from scratch, when they could have simply based on a BSD instead, avoiding the whole GPL issue? Certainly, Google's got a lot of money to throw around if it wants, but as equally certainly, it's not going to have it for long if it starts doing such useless things as a from-scratch Linux reimplmentation when it could have started with one of the BSDs instead.

Also, keep in mind that as Greg KH and others are fond of pointing out, Linux now runs on the widest variety of hardware, with drivers for the widest variety of hardware, of any OS out there. And while the USER application binary interface (ABI) as expressed in those headers may be fair game, the in-kernel modular interface expressly is NOT, with many internal kernel declarations exported for module use specifically as
GPL-only and with specifically NO stable internal ABI, so they can and often do change kernel to kernel. Despite the ability to legally write to the publicly exported USER interface, that's going to leave any non-GPL rewrite without the legal ability to use all those drivers, etc, and it's technically a moving target if they try. Which puts any attempter severely in the hole again, as compared to just starting with one of the BSDs, for instance.

So it's unlikely to happen, unless of course perhaps as a personal hobby, perhaps of some random Finnish college student... and who could rightly predict where THAT might lead! =:^)

Duncan

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 14:08 UTC (Mon) by spaetz (guest, #32870) [Link]

> I have yet to encounter a kernel developer who is concerned about the use of header files in bionic.

Well, given that many employee's code will probably have (c)BreadPayingCompany, it only takes, say, someone to buy Novell (or all its IP), or bribing Nokia to launch such an action. Both possibilities are not totally improbable :-).

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 2:23 UTC (Mon) by wahern (subscriber, #37304) [Link]

It's highly improbable that by purchasing and using an Android phone the user would be doing anything illegal under Copyright law. Here are the exclusive rights a copyright holder has over their material:

http://www.law.cornell.edu/uscode/17/usc_sec_17_00000106-...

The only feasible avenue of infringement is #1, copying. By turning on the phone, you're initiating various copies of the software to made in memory. But there are two interdependent problems here.

(1) To be a "copy" in the sense of copyright, it must be in a tangible form by which it can be perceived. Though RAM copies can definitely be considered tangible and perceptible--by, for example, controlling video--much turns on whether the content of those copies are eventually somehow made perceptible. Just because it's in RAM doesn't make it perceptible if there's no normal mechanism to make it perceptible.

(2) Just because Android applications may be derivative of the GPL'd header files, does *not* mean that they necessarily contain copyrightable content from the header. There are separate technical and legal arguments here. Thus, though the creator may be liable to the Linux kernel copyright holders for making derivative works, the user of those derivative works would be violating that copyright by making in-memory copies only if the derivative work actually contains embedded copyrighted expression from those header files.

There are strong reasons, using either or both of these points, that a user would be doing nothing wrong by using an Android phone.

But there's also a couple of more practical points. For one thing, the user would never be sued. And even if they were there are strong defenses concerning notice. Secondly, from an ethical standpoint, people violate copyright constantly. No person can not violate copyright. Ever hear a tune on the radio and type a few lines of lyrics in an e-mail? That's a copyright violation. Multiple if you actually sent the e-mail (copying, plus distribution, plus maybe displaying if going to a list).

The nature of copyright law is that there are huge grey areas, and everyone and everybody has violated copyright more times than they'll ever possibly know (in ways that are completely black and white). There is no rational reason to think that by using a Windows CE or Symbian phone that you're not also violating someone's copyright (if in the Android case you would be).

The problem with fixing copyright is the same problem that exists when you make any rule of law more clear; you then make it easier for the scofflaws to subvert the intention of the law.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 2:32 UTC (Mon) by wahern (subscriber, #37304) [Link] (1 responses)

Oh, and a third reason no copyright violation. Perhaps the most obvious. The GPL gives that user the right to use the software and derivatives! (To the limit of the original copyrighted work; it can't give rights to others' expression.) Just because the derivative author is violating the terms of the license doesn't mean that you don't get a license to use that original software. And unless you distribute that software further, you don't need the source code; you can make all the in-memory copies you want.

In fact, that's an exceptionally strong argument for using an Android phone instead of Windows CE or Symbian or other any not Free Software OS. It's more likely than not that those phones are violating someone's copyright, yet you would never receive the benefit of the GPL license and so would be infringing yourself.

So really, anyone concerned with abiding by the letter of Copyright law should be using Android phones.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 5:37 UTC (Mon) by FlorianMueller (guest, #32048) [Link]

Oh, and a third reason no copyright violation. Perhaps the most obvious. The GPL gives that user the right to use the software and derivatives!

The concern I discussed isn't really about lawsuits against users -- those are a hypothetical possibility but it's hard to see why anyone would do that. The concern is about device makers and app developers who built software that may be copyleft-affected and could be enjoined from distributing it on non-GPL terms. Of course, if that happened, it would also affect users: potential users who can't buy until the issue is settled, and actual users who can't get upgrades until that point. But that's not the #1 concern.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 2:50 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (5 responses)

I think your response is reasonable, but if I recall correctly, the Linux kernel does not have any form of copyright assignment and therefore all contributors per se are copyright holders.

#include <ianal.h>

But copyright holders in what? The assumption that everyone seems to make is that Linux would be treated as a compilation, where individual authors hold copyright on their specific contributions. So somebody who only worked on network drivers wouldn't be able to claim that their copyright had been violated by Google using kernel headers. Somebody could claim, though, that Linux is actually a collaboration, where everyone who worked on it would have a share in the copyright on the whole. That makes some sense, since the whole thing can be compiled into a single binary.

Nobody knows for sure which theory of copyright would hold in practice, since the issue has never been litigated. I doubt that anything with a copyright situation anywhere close to as complicated as Linux's has ever been completely litigated. Even if the collaboration theory held, a judge might rule that a specific author's contributions were small enough that the violation was de minimus and dismiss a suit for that reason. I'd certainly expect standing to be a big issue in any copyright violation suit involving Linux.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 3:00 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

My loose (and, obviously, I am not a lawyer) understanding is that under US law the kernel could be considered either a joint work or a collective work. In a joint work I believe that any copyright holder could enforce the copyright of the entire work - but the flipside of that is that any copyright holder could also grant a non-exclusive license to anyone else, absent contractual obligations. In that case anyone holding copyright on a portion of the kernel could grant permission for the entire kernel to be used under terms other than the GPL.

It seems more likely that the kernel would be considered a derivative work, ie one in which each author only holds copyright over their specific contributions. I don't know that that's ever been tested in court, but nor am I busy establishing a business case for licensing the kernel to Microsoft in return for a couple of yachts.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 6:08 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

I don't want to comment on your view of US law, but I would like to stress that it's not just about that one jurisdiction. The question is whether Google is safe in the fastest as well as the most difficult jurisdiction that represents a significant market. I just recently researched and reported on the seizure of 300,000 PlayStations in Europe. That decision was achieved within a few days, and on a legal basis that doesn't have an equivalent concept in the US (the closest thing there would be an ITC proceeding, which takes 16-18 months however). It's an example of how someone who seeks to assert rights may just pick the most convenient place. The PlayStation seizure was based on the alleged infringement of intellectual property rights. (In this case, the seizure order was lifted -- lucky Sony.)

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 18:39 UTC (Mon) by rahvin (guest, #16953) [Link]

And the decision was vacated a short time after they were seized and all the consoles impounded were promptly released back to the manufacturer for distribution in the EU. So now your FUD is that it's dangerous in Europe, where's the evidence? The EU case law? You are citing a paper prepared on the basis of US law and citing it against EU precedent. Now that's out there.

Has Bionic stepped over the GPL line?

Posted Mar 23, 2011 17:26 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

My loose (and, obviously, I am not a lawyer) understanding is that under US law the kernel could be considered either a joint work or a collective work

I'm not sure if the kernel would wind up being considered exclusively one or the other. It would be perfectly reasonable to consider each individual source file a joint work (what I called a collaboration) of the people who contributed to that individual file, while the source tree as a whole would be considered a collective work (what I called a compilation). Since the compiled kernel is a derivative of the whole source tree (delta any files that are configured out), it would be a joint work of all contributors.

And, of course, there are other little twists to consider. If I contributed a file 10 years ago that's still in the kernel, but all of the original code has been gradually ripped out and replaced, do I still have a valid copyright interest in the current version of the file? Does it matter if some of the comments I included in the original file, like a description of the file's purpose, are still there? What if the functions were taken out of the file, moved to other files, and later replaced; do I have some interest in the files that once contained functions I wrote? Does it matter if the functions were replaced before or after they were moved? This is potentially important if it turns out there are legal problems with my contribution, e.g. it's not really my work but copied from some other, GPL incompatible work. It's possible that there's a legal precedent describing something like that, but as IANAL I don't know the answer.

In a joint work I believe that any copyright holder could enforce the copyright of the entire work - but the flipside of that is that any copyright holder could also grant a non-exclusive license to anyone else, absent contractual obligations.
On the second part, the GPL would probably constitute the "contractual obligations" that would keep any author from relicensing willy-nilly. Anyone who contributed after the code was put under the GPL did so pursuant to that license; they're only allowed to make contributions with the understanding that the whole will be licensed under the GPL. That probably forbids them to relicense the work as a whole under other terms.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 9:39 UTC (Mon) by ekj (guest, #1524) [Link]

True. So the only thing you can say is that an author who wrote a specific piece *certainly* has standing to complain about violations affecting the piece he wrote.

Either he has standing because he wrote that specific part, or he has standing because he holds joint copyright on the kernel as a whole.

This particular muddling is nonsense though. Worse than that, it's like nonsense for several distinct reasons, any ONE of which would be sufficient.

Has Bionic stepped over the GPL line?

Posted Mar 20, 2011 23:05 UTC (Sun) by ewan (guest, #5533) [Link] (7 responses)

The interesting claim seems to be this one:
But if Google is right, if it has succeeded in removing all copyrightable material from the Linux kernel headers, then it has unlocked the Linux kernel from the restrictions of GPLv2. Google can now use the "clean" Bionic headers to create a non-GPL'd fork of the Linux kernel, one that can be extended under proprietary license terms.
Which as far as I can make out is utter nonsense, possibly based on the misapprehension that the header files are the complete kernel source. Is there any substance to this at all?

Has Bionic stepped over the GPL line?

Posted Mar 20, 2011 23:08 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (6 responses)

No, it isn't complete nonsense. They would "only" have to write the rest of the kernel to implement what the header files promise.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 0:02 UTC (Mon) by AndreE (guest, #60148) [Link]

Yes but is reverse engineering the kernel the same as forking? I don't think so.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 0:32 UTC (Mon) by rsidd (subscriber, #2582) [Link] (3 responses)

Which isn't news and isn't a GPL violation. FreeBSD's linuxulator has been doing exactly this for a while, if I understand right. It isn't complete but runs a lot of proprietary Linux binaries very well.

Actually, I wonder why Google didn't just go with BSD, as Apple did. But one assumes their lawyers are thoroughly satisfied with what they did...

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 0:38 UTC (Mon) by swetland (guest, #63414) [Link] (2 responses)

The Linux vs BSD decision was made before Google acquired Android.

While starting with NetBSD's kernel was tempting, the Linux kernel wasn't that much larger (one of the concerns), had quite a lot of support from silicon vendors and OEMs, and a larger developer community (easier to find folks with Linux kernel expertise).

The bright line between the kernel and userspace drawn by the statement at the top of the Linux COPYING file was certainly helpful in making this decision. Explaining that the kernel is GPLv2 and userspace is Apache2/BSD/MIT is something easily understood by OEMs, and most OEMs don't have a problem with the general idea that the kernel is not where you differentiate your products.

- Brian

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 4:19 UTC (Mon) by b7j0c (guest, #27559) [Link] (1 responses)

i don't find these reasons compelling

had google gone with netbsd or freebsd, the "expertise" issues would be very far back in the rearview mirror by now. there was a huge pent-up demand for something to compete with iOS...people would have figured out what was needed and moved forward.

likewise with java (dalvik, whatever). google also flubbed this decision and whether there substance to the oracle complaint or not, it is just one more distraction that will keep google from concentrating on making great software.

apple demonstrated that a great product can overcome mindshare and educational issues...how many current iOS devs had ever touched objectiveC before buying an ipone?

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 4:41 UTC (Mon) by swetland (guest, #63414) [Link]

Compelling or no, there they are.

Do keep in mind that Android predates any public knowledge of iPhone by several years and that also came into being as a startup, not necessarily expecting to have the kind of impact up front that a company like Google might have.

Either way, I believe choosing the Linux kernel has turned out to be a good decision. We're happy with it technically and that's what matters the most. The platform's doing quite well -- I believe the latest figures we've mentioned publicly (during Eric's keynote at MWC) are 170 compatible devices, 27 OEMs, 169 carriers, 69 countries, and over 350,000 new devices being activated each day.

I've seen a lot of doom and gloom predicted from the moment we announced the platform and the SDK in late 2007 all the way through present day, but so far things have gone well despite the doomsaying.

- Brian

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 0:42 UTC (Mon) by HelloWorld (guest, #56129) [Link]

They would "only" have to write the rest of the kernel to implement what the header files promise.
That wouldn't be a fork of the linux kernel but a reimplementation. Calling it a fork like this guy is going is utter nonsense.

Has Bionic stepped over the GPL line?

Posted Mar 20, 2011 23:05 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Even better. If a bionic must be distributed under the GPL, then libc ALSO should be distributed under the GPL!

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 0:25 UTC (Mon) by ras (subscriber, #33059) [Link]

Excellent article, very clearly written. It is without a doubt the best article I have seen on the subject to date. Thanks.

What's the point of this article?

Posted Mar 21, 2011 0:46 UTC (Mon) by HelloWorld (guest, #56129) [Link] (51 responses)

I mean, seriously, aren't there more interesting topics to write about than lawyers making up lots of bollocks about bionic?

What's the point of this article?

Posted Mar 21, 2011 1:47 UTC (Mon) by corbet (editor, #1) [Link] (48 responses)

Sorry you didn't like it. I think it was worth doing. When there is confusion about a topic (and there are plenty of articles out there suggesting that such confusion exists here) it makes sense to try to bring a little light.

What's the point of this article?

Posted Mar 21, 2011 2:30 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Please go on writing about what suits your fancy. Sure, there have been articles that I personally don't care about (probably even a few each week), but there are more than enough others that do interest me higly.

Keep up the excellent work!

You, go, Jon!

Posted Mar 21, 2011 2:43 UTC (Mon) by tseaver (guest, #1544) [Link] (36 responses)

I appreciate the exposition from somebody with a long history with the kernel as a software artifact and with the developers. Calling bullshit on the lawyers (and other peanut-gallery pilers-on) is a worthwhile use of LWN's mindshare.

You, go, Jon!

Posted Mar 21, 2011 4:14 UTC (Mon) by wahern (subscriber, #37304) [Link] (34 responses)

You have to admit, though, that's it's pretty galling of Google to process source files and strip copyright statements! And while it's inevitable for lawyers and legal professors who aren't also programmers to get some of their facts wrong, the arguments occurring in the legal sphere aren't "bullshit." Google is definitely rocking the boat, and you have to ask yourself which is better for the GPL--a state of legal uncertainty or of certainty. The answer is far from clear.

Here's the problem as far as I see it. While it might seem clear to us that a user-land program compiled against GPL'd kernel headers is not derivative, that will not be the question that goes to court (if this issue goes to court). The question that will go to court is, are Google's processed headers derivative of the unprocessed headers? That question is much closer, and if it comes out that they are derivative, it means that it's more likely that the first question will be answered that user-land programs are derivative. The outcome of this case would change the course of the law in an unexpected way.

And the fact that Google is running a simple program to mechanically process those headers... that's not the best case for a defendant to carry into court. It's one thing to re-create those headers by hand, it's another to mechanically transform them, the legal theory of derivative works notwithstanding.

You, go, Jon!

Posted Mar 21, 2011 4:59 UTC (Mon) by sfeam (subscriber, #2841) [Link] (5 responses)

If header files are not copyrightable in the first place, a position for which there is some precedent, then issues of stripping or not stripping, mechanically or manually, are moot.

You, go, Jon!

Posted Mar 21, 2011 6:00 UTC (Mon) by wahern (subscriber, #37304) [Link] (4 responses)

What precedent? I'm not aware of any precedent. (If you know of legal precedent, I would like to know about it. IANAL, but I intend to play one someday.)

Also, it's worth noting that Edward Naughton's description of Sega Enterprises v. Accolade (9th Cir. 1992) is totally wrong. (Atrociously wrong, in fact.) He used it as a possible defense for Google, but that case is quite the opposite. First of all, his description is totally wrong. Sega v. Accolade said that the disassembly *was* copyright infringement, but that it was a Fair Use. And it said that it was a Fair Use *not* because the copied code embodied the *idea* of interoperability (it rejected that subject-matter argument, as have most other courts), but only because it was the only way to get at otherwise uncopyrightable material.

In other words, the idea that particular source code is not copyrightable because it "merges" with the idea of interoperability or compatibility with an operating system is a bogus argument. (Rejected in Sega; rejected in Apple Computer v. Franklin Computer (3d Cir. 1983). Rejected in other cases.) The only way Google's theory holds water is if the source code at question itself is completely uncopyrightable, whether in a header file or any other file. And that means it must be bereft of any original creativity. (Under the Feist analysis, which found no copyright in a phone book because it listed residences in alphabetical order--an uncreative compilation of facts; begging the question of whether some other creative listing not in alphabetical order might be sufficient creativity to protect the phone book.)

Frankly, as a programmer I'm not so sure I want Google to be right.

Google can be wrong yet Android applications still be safe. Google could be wrong that a 10-line inline function is not copyrightable; but correct that a typedef is not copyrightable. And as long as the app only depends on the typedef and not the inline function, all is fine. Google will merely have to stop stripping copyright notices from source files--GPLv2 sec. 1 requires that the licensee "keep intact all the notices that refer to this License."

I suspect Google's legal theory is born of the abstraction/filtration/comparison test described in Computer Associates v. Altai, 982 F.2d 693 (2d Cir. 1992). Reading the case, or part III, or at least section III.A(2), is like a mini-education in copyright law as applied to computer programs. http://www.bitlaw.com/source/cases/copyright/altai.html

You, go, Jon!

Posted Mar 21, 2011 6:17 UTC (Mon) by wahern (subscriber, #37304) [Link]

I should be more clear. Merely because a header file describes a kernel interface doesn't mean that it's not copyrightable on an interoperability theory. It's copyrightable merely if the description itself is sufficiently creative. One way it would not be creative is if the expression is dictated by efficiency concerns, or general engineering best practice. But it's not lacking in creativity merely because it's describing some other code, and therefore hemmed in by the necessity of describing that other code. Even if the header is perfectly dictated by what it's describing (i.e. there's only one way to create the header), if what it's describing is copyrightable than so is the header.

Otherwise, a table of contents wouldn't be copyrightable merely because it's describing the book. But if each chapter heading has a creative aphorism, so does the table of contents; therefore the table of contents would be copyrightable.

Now, if you processed the table of contents, stripped out the chapter headings and were left only with a table of chapter numbers and pages, you would be solid. But that is not what Google is doing. If you think that by stripping out the comments all the copyrightable expression is gone, then you're implying that huge bodies of source code are not copyrightable by themselves, no matter what. That's a dangerous precedent.

Note that this isn't like the SCO case at all. That's a false comparison on so many levels.

You, go, Jon!

Posted Mar 21, 2011 18:33 UTC (Mon) by butlerm (subscriber, #13312) [Link] (2 responses)

What precedent? I'm not aware of any precedent. (If you know of legal precedent, I would like to know about it. IANAL, but I intend to play one someday.)

Try Baystate v. Bentley Systems (1996), which held that technical interfaces are not copyrightable, including structure layouts and element names. See here (pdf). It is hard to see what could be left in a stripped interface header file, other than complex macros or inline functions, which presumably have much stronger protection.

You, go, Jon!

Posted Mar 24, 2011 6:49 UTC (Thu) by branden (guest, #7029) [Link] (1 responses)

That's useful, but I cannot find any record that this decision was appealed.

This is important because the holdings in the case were by a federal *district* court. If it had been appealed, it would have gone to a federal appellate court--the holdings of appellate courts are binding upon that court's jurisdiction (the district, the circuit, or the entire U.S. depending on the appellate court level).

District Court opinions do not constitute precedent in the United States. Any court anywhere in the U.S., including that *same* district court, is at liberty to completely disregard the findings and results in this case (unless they have a local rule to the contrary, which might be the case).

You, go, Jon!

Posted Mar 24, 2011 16:24 UTC (Thu) by butlerm (subscriber, #13312) [Link]

District court decisions do not count as binding precedent, certainly. That doesn't mean they aren't widely influential, in terms of logic and reasoning. The idea is to interpret the law, not make it up, right?

If the district court's ruling is a tour de force of rationality, any other court is going to have a difficult time issuing a contrary one. This particular decision treated the issues here in greater depth than any previous U.S. court, and should reasonably be treated as a guide to the way other courts would rule when faced with the same question.

What Google's actually doing

Posted Mar 21, 2011 5:15 UTC (Mon) by jthill (subscriber, #56558) [Link] (26 responses)

What's left after their filter runs is, according to them, only the uncopyrightable part. There definitely is such a thing; the applicable standard for headers was settled in 2004 if not before.

And I think they have it right: "scènes à faire" material is material that has to be as it is in order to make things work. Presuming so:

There's nothing wrong with copying only what no one has a right to lock up, and nothing wrong with leaving the copyright notice behind with what it refers to.

Even if someone were to go to court claiming the headers themselves were still copyright, despite well-known and settled precedent, that still wouldn't begin to produce the kind of downstream uncertainty the shills are trilling about. Derivation isn't a one-drop-of-machine-oil-in-the-drinking-cistern thing: in order for inclusion to taint the result, the result's similarity to the original must be "substantial". Is your program, the work you produced and distribute, taken as a whole, substantially similar to any selection from linux/*.h? I thought not. You're safe, as is anyone using the headers Google supplies.

Anyone can sue anybody for anything, but the only possiblity here that's not completely laughable would be someone trying Google on for their interest in one or more of the headers. Whoever tried that would lose in as decisive, degrading and humiliating a defeat as SCO did years ago. I don't imagine anyone, no matter how well lubricated, is going to willingly go down that road.

What Google's actually doing

Posted Mar 21, 2011 6:46 UTC (Mon) by wahern (subscriber, #37304) [Link] (25 responses)

The scènes à faire argument doesn't suffice to explain their _wholesale_ copying. The idea that Linux's ctype.h header, for example, isn't copyrightable because it's describing a well known, published, operating system standard is based on the fact that there's really only one way to accomplish that description, and there's an implication that that element of the POSIX standard isn't copyrightable.

But a header describing an interface unique to a body of copyrightable code is completely unlike scènes à faire. Scènes à faire applies to plot devices like film noir private investigators. The mere fact of using one of those does not implicate infringement of some other movie also using those; because they both derive from a common cultural fountain. But if your film noir private investigator is Bob Smith, and so was the other movie's; and if both have a tattoo on their cheek, and various other character traits; that's not scènes à faire. Those specific things aren't drawing from a common fount of material.

Likewise, there's only one Linux. You can't copy Linux's interfaces based on the "idea" of compatibility with Linux's interfaces. That's like making an Indiana Jones sequel based on the "idea" of an Indiana Jones sequel. Indiana Jones isn't an idea; it's original and creative characters and plot devices aren't scènes à faire.

The only way you can copy it's interface descriptions without infringement is if the description itself is devoid of any copyrightable expression; no matter that it's intended for interoperability with the kernel. Yes, there are doubtless many examples of this. But to think that *every* structure, *every* inline function, *every* macro, or *every* collection of such things, is not copyrightable is extremely bold. And if you're right, it means that code of similar expressiveness in any source file is also not copyrightable.

Maybe that would be a good outcome for the software industry. But my gut reaction is that it would make it difficult for Free Software developers to prevent proprietary ripoffs of large chunks of code.

Also, you seem to be conflating issues of (a) substantial similarity, (b) what constitutes derivative works, and (c) Fair Use analysis. Suffice it to say there's not enough room or space to dive into those issues well enough here.

What Google's actually doing

Posted Mar 21, 2011 9:51 UTC (Mon) by foom (subscriber, #14868) [Link] (20 responses)

So you're arguing that userspace programs running on linux using those APIs actually need to be GPLed, despite the kernel authors' intent?

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 12:25 UTC (Mon) by dank (guest, #1865) [Link] (19 responses)

I think wahern is arguing that you need to strip out anything in the
headers that is not actually required to compile working apps.
That was clearly Google's intent, and if they succeeded, I think
they have met Linus's intent as expressed in his emails (and understood
in context, i.e. since Bionic is not a loadable kernel module, one
shouldn't apply Linus's comments about LKMs to it).

Let's examine the resulting headers to see how close Google came to this,
and see if we can find particular lines that are not forced by the kernel ABI.

I looked at one file,
http://lxr.e2g.org/source/bionic/libc/kernel/common/linux...
and saw a few things that seem like they could have been stripped out.
Two examples:

CONFIG_EXT3_INDEX is not unreferenced anywhere (see
http://lxr.e2g.org/ident?i=CONFIG_EXT3_INDEX )

ext3_debug is only referenced inside the kernel, and is defined by
the unstripped kernel headers (see
http://lxr.e2g.org/ident?i=ext3_debug )

I didn't see anything that is both required and 'expressive'.

I suspect the only thing Google ought to do is remove the symbols from the
headers that are not referenced by bionic, but since they're not
referenced, no actual harm has been done.

(Hi, Florian! Are you the same Florian I knew at Knowledge Adventure?)

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 14:42 UTC (Mon) by wahern (subscriber, #37304) [Link] (18 responses)

I agree that no significant practical harm is done if, in fact, nothing derivative has accidentally been caused to be created by third parties.

But the issues of third-party derivative works and Google's violation in stripping the license notices are separate. The only thing I'm arguing is that Google is likely violating copyright because they're not stripping all the expressive elements from the headers, and so had no right to remove the license notices. But whether a particular Android application is derivative of GPLd headers is a significantly more complex issue. Related, to be sure; but distinct.

For example, Linus's original caveat may be implicitly adopted by all the other contributors, and much like section 3 of the LGPLv3, grants the ability to incorporate or otherwise transform certain header code, such as "data structure layouts and accessors." But of course, such a right could only be granted if such elements were copyrightable; otherwise there would be no right to grant. That this section was inserted by the FSF doesn't mean they believe the elements were truly copyrightable, but clearly they had sound reasons for at least hedging. If the situation was so cut and dry, it would never have been added.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 15:31 UTC (Mon) by dank (guest, #1865) [Link] (16 responses)

To summarize my (weak) understanding:

0) Semantic information needed for userspace (libc or apps) to interoperate
with the kernel via public interfaces is either noncopyrightable because it's a published interface intended to be publicly usable, and/or can be used without infringing because Linus said so

1) The expression of that information in a particular header is copyrightable

2) A compiler or other semantic analyzer can extract the noncopyrightable
semantic information from a copyrighted header and dump it to a new sanitized header without infringing the header's copyright

3) Google intended to do that, but didn't quite do a thorough job, so there may be some residue of expressive, non-required, copyrightable code in the headers

4) The residue is probably not being referenced by Bionic or any third-party apps, so there are probably no infringing derivative works

5) Google could reduce the amount of residue if they wanted by adding
another scrubbing pass in the header filter code to remove symbols
not referenced by bionic libc or the apps that come with android
(and for that matter, replacing all possibly expressive whitespace);
this would strengthen their case that removing the license notices
is appropriate. Doing so now would be a fine example of responding to
a possible GPL violation in good faith.

6) Semantic information needed for kernel modules to interoperate
with the kernel via nonpublic interfaces is another matter, and does
not affect the Bionic discussion

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 15:34 UTC (Mon) by wingo (guest, #26929) [Link] (15 responses)

> 2) A compiler or other semantic analyzer can extract the noncopyrightable
> semantic information from a copyrighted header and dump it to a new
> sanitized header without infringing the header's copyright

This doesn't sound right; otherwise one would be able to do the same for source files as well.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 16:14 UTC (Mon) by dank (guest, #1865) [Link] (14 responses)

IANAL, but:
In the US, law recognizes that the boundary between "disallowable copy of the expression of an idea" and "allowable reuse of an idea" is a fuzzy one, and tends towards allowing the use of really simple, essential ideas (like how the lines of a financial table are laid out, or how the elements of a struct are laid out).
See http://www.bitlaw.com/source/cases/copyright/altai.html

Since the sanitized headers are (or should be) just a bunch of names, table offsets, sizes, and similar things, their use is likely the allowable reuse of ideas. This reading is bolstered by the fact that the authors of those lines of the kernel marked them with #ifndef __KERNEL__ to indicate they were intended to define the API to be used by userspace.
See http://lwn.net/Articles/244375/

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 3:52 UTC (Tue) by wahern (subscriber, #37304) [Link] (13 responses)

Here's the issue reduced to it's simplest form:

struct foo { int x, y; };

#if __KERNEL__

struct bar { int x, y; };

#end /* __KERNEL__ */

Now Google says that this is not copyrightable:

struct foo { int x, y; };

What, then, makes this copyrightable:

struct bar { int x, y; };

Either they both are, or neither. Whatever it is that makes one copyrightable also makes the other copyrightable; they rise and fall together. Whatever transformation makes one not copyrightable could make the other not copyrightable. They're symmetric. Those magic __KERNEL__ guards don't effect whether one section or the other can be copyrighted; they merely outline the contours of the explicit and implied license grants once we've established actual, copyrighted material.

The same symmetry applies further up the ladder. Either kernel interfaces are protected expression and Google is violating their license by stripping notices, or Google is in the clear and kernel interfaces en toto aren't protected. Again, the boundaries of those magical __KERNEL__ guards don't dictate what interfaces are copyrightable. The same Altai, SCO, et al analyses of copyrightable subject-matter apply equally across the board. For every ctype.h outside of the include guards, there's something equally insubstantially expressive within the include guards; and for every copyrightable selection within the include guards there's something equally substantially expressive outside of the include guards. It doesn't matter what the test is: qualitative versus quantitative, too abstract versus de minimis creativity.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 4:13 UTC (Tue) by dank (guest, #1865) [Link] (5 responses)

One story is that most examples of 'foo' are specified by
POSIX, and are stable, whereas most examples of 'bar' are unstable
internal kernel interfaces.
POSIX interface documentation is also available under a free license, see
http://www.redhat.com/archives/fedora-legal-list/2007-Dec...

But that's not enough; what about the other 'foo's that are part of Linux's extensions to POSIX?

Linus wrote on 19 Oct 2001 (see http://linuxmafia.com/faq/Kernel/proprietary-kernel-modul...):
"If you use standard UNIX system calls (with accepted Linux extensions), your program obviously doesn't "derive" from the kernel itself."

So there y'go. It's different because Linus said it is.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:23 UTC (Tue) by wahern (subscriber, #37304) [Link] (4 responses)

Just peruse the Android git tree. We're not talking about syscall tables for POSIX interfaces. Those sorts of things constitute a mere fraction of the total of their tree. Most of the tree defines interfaces to Linux-original subsystems.

Yes, most of the unguarded sections are meant to be used in user-space. That's inconsequential. That's like saying all of your header files for your libfoo are not copyrightable. What does it matter what it's going to be used for? What makes something copyrightable is inherent in the content, not the authors' intentions for it.

And the question of how "thin" your copyright can be in headers doesn't amount to much, either. Can there be copyright in "struct foo"? "struct foo; struct bar;"? "struct foo; struct bar; struce t baz"? Google is saying it doesn't matter. No code in headers is copyrightable, period. Which amounts to saying that copyright can't subsist in the definition of your API. Which begs the question, if an API isn't copyrightable how can you prevent derivative use of that API? You can't. Not until your code is linked and loaded and running with the implementation would it be derivative. Which means there's no functional difference between the GPL and LGPL, if what they're doing is legal.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:59 UTC (Tue) by viro (subscriber, #7872) [Link] (2 responses)

Oh, for pity sake... Use of system calls is NOT MAKING YOUR CODE DERVATVE. POSIX or not, doesn't matter - just read the sodding license, already. Permission to use the definitions needed for use of said system calls follows from that.

And frankly, what you are trying to push is vile. On par with look-and-feel copyrights.

Incidentally, if libfoo provides only one function that takes no arguments and returns int, not adding any #include at all will *NOT* allow you to escape the need to comply with the license of libfoo. And no, it's not because the identifier "foo" in int n = foo(); is copyrightable.

Get a clue, get a life and piss off, already...

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 16:42 UTC (Tue) by wahern (subscriber, #37304) [Link] (1 responses)

Not one thing you said in your comment disputes what I said, nor do I disagree with the specific points you made other than your slights against me. If only you would read English as closely as C.

And I will piss off. You can continue living in the dark. And you can continue thinking that you have to cling to an improper understanding of the issue because of some other consequence you can neither perceive nor articulate. You're inability to distinguish the legal argument from your commitment to supporting Google's otherwise laudable work is disappointing.

Good day, sir.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 16:53 UTC (Tue) by wahern (subscriber, #37304) [Link]

Actually, upon more careful reading I do disagree with what viro you said, because it's conflating copyright subject matter with licensing. What makes something derivative is a matter of law that can't be avoided by a license. Though I'm not disputing that mere use of a system call does not necessarily make something derivative (I'm not insinuating anything by being circumspect with my words, either); nor that a license can make derivative use okay.

I respond only to protect my name; what with archiving and all. I'm not returning to this thread for the foreseeable future.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 15:52 UTC (Tue) by sfeam (subscriber, #2841) [Link]

Bingo. Despite your implicit scepticism, this is the correct analysis. There is no functional difference between the GPLv2 and LGPLv2 in the case of an external library that is being linked. I limit that statement to v2 simply because I haven't examined v3 in enough detail to have a separate opinion. The FSF argues otherwise, but that does not make them correct on this point. You pointed that out yourself: "What makes something copyrightable is inherent in the content, not the authors' intentions for it." IANAL and all that.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 4:40 UTC (Tue) by swetland (guest, #63414) [Link]

I can't comment on theory about what's copyrightable or not (I'm not a lawyer), but I can offer this fact:

The primary motivator in subsetting the kernel headers is to end up with a minimal set of headers necessary to encompass the userspace<->kernel interface surface, and avoid clutter, confusion, or future brokenness by avoiding exposing userspace to anything more than is strictly necessary to make calls into the kernel.

From a support standpoint, anything in headers that doesn't need to be there (as far as structures, function declarations, etc) is something that might break when we refresh the headers from a newer kernel version.

Knowing the habits of application developers, if we didn't yank the #if __KERNEL__ sections, *somebody* would inevitably write code that #define __KERNEL__ 1 and included some linux header for some absurd reason and then they'd be cranky if it stopped working in the future.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 12:28 UTC (Tue) by ekj (guest, #1524) [Link] (3 responses)

In this particular example, both would probably be judged to be trivial, and to lack sufficient content to be worthy of copyright. Exactly what is worthy, varies by jurisdiction, but I'm not aware of any where "struct foo { int x, y; };" would suffice.

Notice, as a parallell, how Wikipedia commons claim, after careful legal review, that a flat-on photo of a 2-dimensional work of art, does not enjoy copyright. (the work of art may or may not, but the PHOTO as such, does not), because there's not sufficient creativity and/or artistic skill involved in the creation.

Copyright protects the expression of an idea, not the idea itself. So if a certain struct, or a certain photo, does not contribute beyond the idea itself, then it's not protected by copyright.

Yes the borders are fuzzy.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:09 UTC (Tue) by wahern (subscriber, #37304) [Link] (2 responses)

I wasn't trying to be literal. There's little doubt that "struct foo" is bereft of original, creative expression. It was merely an exercise which in substance is no different when you apply the analysis to the larger tree.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 23, 2011 8:18 UTC (Wed) by ekj (guest, #1524) [Link] (1 responses)

Like always with non-trivial question the answer is "it depends".

Some people in CompSci tends to think in overly strict principal lines, wanting the grey to go away. Perhaps this has something to do with how a computer works, in binary. But it's not how law works.

If one sentence contains insufficient creativity and/or artistic skill to be worthy of copyright, it does -not- follow that 50 similarily well-written sentences as a whole *also* does not deserve copyright.

In practice, merely doing more of the same, can give copyright. The creativity and/or artistic skill which is there adds up, and at some point crosses the threshold. This message as a whole, for example, may well be sufficient - whereas any individual sentence in it, would likely not be. (and I'm sure many of the sentences have been used in a very similar form before by others)

What I'm saying is, you *cannot* generalise from trivial examples to the whole tree. It's certainly possible that each of the examples, in isolation, is unprotected, while the sum total is protected.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 23, 2011 19:26 UTC (Wed) by martinfick (subscriber, #4455) [Link]

> Some people in CompSci tends to think in overly strict principal lines, wanting the grey to go away. Perhaps this has something to do with how a computer works, in binary. But it's not how law works.

Or perhaps it's how reasonable people think? Many laws are designed to be wishy washy so that the people who speak in vague illogical terms and who spend money on lawyers can take advantage of those reasonable people who don't. Copyright is just one of the many examples of this. Patents are an obvious other.

The fact that this discussion is currently over 100 comments of bickering over the understanding of copyright, likely by professionals who actually operate in the copyright field daily, should tell you that the concept of copyright is beyond grey, and very vague. This is not a subject matter that any law could ever be fair about. It is not a subject matter that you could expect juries to reasonably agree upon in a consistent matter. It is simply a bad use (not just a bad implementation) of law.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:43 UTC (Tue) by foom (subscriber, #14868) [Link]

So what are you arguing? That every userspace program is a derived work of the Linux Kernel? Because there's nothing substantially different from what glibc is doing than what bionic is doing; they rise and fall together.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 23, 2011 21:06 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Either they both are, or neither. Whatever it is that makes one copyrightable also makes the other copyrightable; they rise and fall together.

Even if both are copyrightable, Google's ability to use them without getting in copyright trouble is not necessarily the same. It may be fair use to copy the public symbols because they are part of a defined interface and hence necessary for compatibility. The same does not hold for the internal interface.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 16:03 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

That the FSF states some right explicitly doesn't mean they think it's theirs to grant: Their stuff is meant more for the average programmer, who probably doesn't know squat about the nuances of what is and isn't allowed by copyright. Better spell it out, even if for somebody with legal training it is obvious. See some of the explanations in GPL for examples of the above.

What Google's actually doing

Posted Mar 21, 2011 9:52 UTC (Mon) by jthill (subscriber, #56558) [Link] (3 responses)

I think if you chase my link you'll find that wasn't the only grounds cited there, either, and as you say dissecting all the gory details could go on forever -- leading to the desperately-sought but false appearance of new scary possibilities.

Here:

the unprotectable elements of ideas, processes, facts, public domain, information, merger material, scènes à faire, and other unprotectable elements suggested by the particular facts of the program under examination.
That's what you have to remove from the allegedly infringing and allegedly infringed works before comparing the two for "substantial similarity".

Also, you seem to be conflating issues
I think if you reread what I wrote you'll see that the appearance was due to your own confusion, not mine. For one instance:

But to think that *every* structure, *every* [...] collection of such things, is not copyrightable
I don't think that. I think that what little remains, after you've stripped the headers of facts and information along with everything else, will be such an insignificant part of the linux kernel, of the ... ummm ... 12.7million-line "body of copyrightable code" they describe, that any attempt to claim substantial similarity to the whole shouldn't even merit laughter.

What Google's actually doing

Posted Mar 21, 2011 14:29 UTC (Mon) by wahern (subscriber, #37304) [Link] (2 responses)

If that is indeed the case (and you may very well be right), than how can copyright prevent distribution of binary modules built against those headers? If the actual header code itself describing a particular interface of the kernel isn't copyrightable (as the same expression or as derivative of the expression), then how can anything be derived from it?

If you say, "well, it's deriving from the interface, not the header code" then how is the header code likewise not also equally implicating this abstract interface? Certainly the header code often describes this interface in more exacting detail than the binary module. Some of the material you cited is predicated on the notion that the interface being described isn't copyrightable for very specific reasons relevant to the particular interfaces at issue--an extremely fact-centric analysis not likely to apply to Google's largely indiscriminate copying, __KERNEL__ guards notwithstanding.

Further more, your substantial similarity argument applies equally well--both quantitatively and qualitatively--to the binary modules' proposed infringement. Clearly, how we slice and dice the scope of the infringement is critical.

For something to be derivative, it must create a sufficient impression in one's mind of identifiable, copy-protected elements of the derived work. If a header file cannot do this, how can a binary module do this? It hardly matters that the binary module doesn't work without the Linux kernel. I can write a story in such a manner that every third page seques into a substantial Phillip K. Dick paragraph. And I can distribute that story, sans those paragraphs, if without those paragraphs you couldn't identify specific copy-protectable elements of Dick's stories. That when you put them together it becomes a derived work hardly matters by itself.

I'm not challenging the soundness of the cases you cite. I'm merely suggesting that those aren't necessarily applicable to Google's wholesale copying of huge portions of Linux kernel header code. And if Google is legally in the clear (which IMHO is doubtful with such a huge collection of code, no matter how thin the copyright), then there are tremendous, potentially undesirable consequences for copyleft enforcement. (Though a BSD-style license proponent might not care, and even might welcome it, as strict license enforcement is of lesser consequence and often creates more confusion than clarity.)

It would be interesting to read your reply, but this shall be my last. I don't mind if you get the last word; in fact I would prefer it ;)

What Google's actually doing

Posted Mar 21, 2011 18:51 UTC (Mon) by butlerm (subscriber, #13312) [Link]

If that is indeed the case[...], than how can copyright prevent distribution of binary modules built against those headers?

It can't. That is wishful thinking at this point, at least under current legal precedents (notably Baystate v. Bentley Systems (1996)). At best the license could be used to regulate joint distribution, and it is difficult to write a general purpose license that can clearly distinguish between joint distribution of copyleft and proprietary stuff which is allowed and joint distribution of copyleft and proprietary stuff which isn't allowed.

What Google's actually doing and Kernel modules proper

Posted Mar 22, 2011 4:03 UTC (Tue) by jthill (subscriber, #56558) [Link]

Well, if I were going to try to make Linus's argument about kernel modules, I wouldn't want to start out exasperated by a blinkered troll to the point of getting all capslocky, as he was.

Before changing the subject, though, let me just say that I've seen propagandists at work before. I'm seeing it again. Don't get sucked in by their misdirection; they will adeptly point in any direction but the ones that silence their alarms, and ignore or change the subject if you go that way yourself. They didn't, for instance, point out what Jake did and vonbrand highlighted, or any number of other obvious and relevant facts. Don't let them choose what you look at. The metaphor of the palantír might be worth revisiting.

One other thing needs addresssing. You say:

Sega v. Accolade said that the disassembly *was* copyright infringement, but that it was a Fair Use
(emphasis mine.) Erm, [citation needed]. Really. The law says, flat out, that no matter what §106 says

the fair use of a copyrighted work [] is not an infringement of copyright.
and the contradictory statement you attributed to the court appears nowhere in 977 F.2d 1510. I looked over it fairly carefully, looking for anything that might have led you to believe what you say. Where is it, please?

=====

So let's change the subject, as you like. From here on, this is just conversation, not debate or argument. It hasn't had time to steep.

The first thing I notice is I'm not sure I agree with Linus, and I'm certain rms disagrees -- at least to the extent that merely including the header does it. (Slashdot pays off with a timely memory). To allege infringement, which is necessary to assert the right to dictate license terms, you have to pass the same test we've been discussing: show that copying occurred, and

whether, as a mixed issue of fact and law, those elements of the program that have been copied are protected expression and of such importance to the copied work that the appropriation is actionable
That, by the way, is not mine, it's the case cited in the IBM deposition I linked, Gates v. Bando,9 F.3d 823. It's at least one of the rules that got the Judge to later caustically refer to "the vast disparity between SCO's public accusations and its actual evidence--or complete lack thereof". So I'm fond of the case anyway, but I like the phrasing because it seems to me it manages concisely stating the general criteria while simultaneously respecting fair use and de minimus.

Anyway, for outside-the-kernel code I agree completely with Stallman (and following Jake's logic, Linus does too; certainly other posters in that thread do): including header material, anything up to pedestrian macros/inlines, cannot bind you. A few structs and an inline, even if they're protectable at all, simply aren't of any actionable importance to the linux kernel. Anybody trying to claim actionable copying there is I think plainly living deep inside anybody-for-anything nutjob/agitator territory.

For in-kernel code it's not so plain, on any count. We have the extent of the copied protected material, the relative importance of the copied portions, and now the resulting harm to the copyright holder comes into play, where nothing reached it before.

Binaries are subject to copyright license terms, we all take that for granted yes? That brings the binaries into question when assessing what elements of the work have been copied, and that means that copying the entire kernel into memory in order to get any benefit of the kernel module is significant: without the full kernel, it isn't just that the source won't run, it's that this so clearly highlights that the work is incomplete without this particular kernel.

From that vantage, "those elements of the program that have been copied" no longer refers only to the portions of the kernel source that appear in the module source, it also refers to the portions of the kernel binary that have been copied into the kernel module -- which, without the kernel binary, is incomplete, so what's actually copied, soon or late, is (virtually) all of it.

That's the part I'm not sure I agree with. Code isn't album tracks isn't movies isn't books isn't blah blah blah. I think _this_ question is fully open to case law, up to any judges involved to decide on the merits of the arguments presented to them what constitutes the resulting "work" with modules necessarily built specifically for a particular kernel version. I also think it's pretty much moot: was the GPL'd-shim stunt invented after his post? Wouldn't surprise me, and it seems not to be drawing any fire from the people who have any standing to bring it.

But I'm not unsure about the objections you raise. They're wrong. I wish you hadn't just dropped them into the thread, I don't think what I find wrong with them is hard to see.

Much as I love the Dick reference. (It seems more apt, more tasty, more, erm, Perky, the longer I contemplate it), details matter. For literature, even two words can be immortal prose, a paragraph is enough to change lives. Binary kernel modules live by different rules, not only by their own nature, but by the kernel's: for starters, books aren't constantly amended by their authors; your writing your literary plugin doesn't seem likely to interfere. So your analogy is much too inexact. As with scènes à faire, I think the concepts still apply, but applying them needs to honor the differences along with the similarities.

I can see that Google's mass-edit offends you and as I think I said earlier it sure got my attention. But there's nothing to see here.

It seems what they're doing is ensnaring a relatively trifling amount of protected code, and as I think I said earlier, there isn't any copyright on just the headers portion of the kernel source any more than there is on any subset of any work: you have to identify the whole work that's being excerpted to properly assess how much was copied. Google's rendered headers do not resemble the kernel. Google's rendered ext2_fs.h does not resemble the kernel's ext2fs module.

The entire net effect that I can see from this is their customers will be very baffled when the alarmists start spewing tripe in their ears about how the GPL eats babies. We already agreed just including a header doesn't even remotely infringe, but that's not what you hear from the shills. So now their customers will have their lawyers look at it, and their lawyers will say "What license terms? There's nothing to license here." This isn't harm, this is a good thing.

What goes in headers isn't like what goes in source. The headers aren't all the source, and copying all the headers isn't the same as copying all of any code any more than copying all the names and descriptions of people mentioned in a newspaper is copying all the stories about them.

So your implicit-slippery-slope argument, that copying the headers is tantamaount to copying everything, just look to me like fearful and thoughtless nonsense. Google is in the clear because the two aren't the same. Leave aside any de minimus test, I'm having a hard time finding any actual harm in it at all -- since afaict no one is relieved of or ducking any actual obligations. But I'm out of patience with this, so if I've missed something please point it out kindly.

You, go, Jon!

Posted Mar 21, 2011 15:04 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Non sequitur. If programs compiled using the kernel's headers aren't derivatives of the kernel, how can programs compiled against other header files be derivative of the kernel? Sure, the munging of the original header files to create the new ones might be suspect, but that doesn't change the above fact.

You, go, Jake!

Posted Mar 21, 2011 12:53 UTC (Mon) by corbet (editor, #1) [Link]

Glad you like it - but do note that Jake wrote this article, not me.

What's the point of this article?

Posted Mar 21, 2011 4:18 UTC (Mon) by rsidd (subscriber, #2582) [Link] (7 responses)

I think it was a very enlightening article. Thanks.

(Incidentally, Mr Mueller -- who till recently enjoyed stirring things up in the comments section of LWN -- seems to have disappeared from this site lately. Good riddance. Dare one hope that, one day, he will actually start checking his facts before commencing his muck-raking?)

What's the point of this article?

Posted Mar 21, 2011 5:48 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (2 responses)

Speak of the devil ;-))

What's the point of this article?

Posted Mar 21, 2011 6:20 UTC (Mon) by jmm82 (guest, #59425) [Link] (1 responses)

literally.

What's the point of this article?

Posted Mar 21, 2011 10:57 UTC (Mon) by nix (subscriber, #2304) [Link]

Not literally. The devil is powerful, and is often spoken of but never seen. Neither of these apply to Florian.

What's the point of this article?

Posted Mar 21, 2011 6:35 UTC (Mon) by bronson (subscriber, #4806) [Link] (2 responses)

Maybe lots of people are using LWN's comment filtering feature? Go to My Account and filter his username. This one change removes most of the stupid (by volume) from LWN's comment feed. Highly recommended!

What's the point of this article?

Posted Mar 21, 2011 7:01 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

Good point and I should do it. There are something like 16 new comments since I checked this morning, of which 11 are by this one guy.

What's the point of this article?

Posted Mar 21, 2011 8:47 UTC (Mon) by FlorianMueller (guest, #32048) [Link]

I have no problem with people filtering out my comments if they so elect. I think that's a basic freedom they should enjoy.

What's the point of this article?

Posted Mar 21, 2011 9:27 UTC (Mon) by jzbiciak (guest, #5246) [Link]

Generally, FM was my hint to hit the "Back" button. It's amazing how someone can be so tireless at being so tiresome.

What's the point of this article?

Posted Mar 21, 2011 5:50 UTC (Mon) by FlorianMueller (guest, #32048) [Link]

The question is whether LWN's article reduces or exacerbates the confusion you're referring to. With the greatest respect, I actually think the latter is the case because you don't say affirmatively that Bionic isn't infringing.

The easy fix argument now made by LWN and previously made by @bkuhn flies (as I explained in my reply to him) in the face of everything that's known in the world of commercial software development about the potential impact (even in counterintuitive areas) of even the smallest change to a large codebase.

What's the point of this article?

Posted Apr 7, 2011 16:14 UTC (Thu) by stevem (subscriber, #1512) [Link]

Good call to cover this Jon, and it's a well written piece from Jake too.

It's also (hilarious|annoying) to see Mueller's attempts to justify his FUD; any chance of a vote to simply drop/ban his account?

This is the point of this article

Posted Mar 21, 2011 5:42 UTC (Mon) by eru (subscriber, #2753) [Link] (1 responses)

The trouble is that lots of people became concerned about this "lawyers making up lots of bollocks about bionic" stuff, or have used it to cast doubt on Android and Linux in general (I saw it happening at my company as well). I definitely appreciate this article, and it will be a fine thing to link to in internal discussion lists on the issue, when it gets publicly viewable.

This is the point of this article

Posted Mar 21, 2011 10:58 UTC (Mon) by brianomahoney (guest, #6206) [Link]

That is the point of Frorian's FUD, to muddy the water, confuse and give aid and comfort to our (not his) enemy M$

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 4:40 UTC (Mon) by b7j0c (guest, #27559) [Link] (4 responses)

i'm not entirely sure why the open source community continues to rally to google's defense. google has excelled at deftly maneuvering around license and copyright issues to create something which on its own, arguably does not satisfy the open source ideals from which the original works were derived.

all of these cases will continue to pile up because there is a grey area here that lawyers will exploit for years to come. had google just made sure their codebase was BSD-licensed and their programming language wasn't being sold to oracle, they'd be in the clear...like apple is today and will continue to be. sorry but the apple lawyers got this one right.

these cases won't kill android, but there's a strong possibility that google will have to devote energy walking a tightrope with regards to licensing instead of builing great code.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 5:59 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

i'm not entirely sure why the open source community continues to rally to google's defense

I wouldn't say that it's "the open source community". In many discussions taking place on the Internet and in real life, there are voices like yours that criticize Google for what they're doing. There are also a number of apologists, but they aren't "the open source community".

That said, I agree with you it's strange that anyone from that community should rush to Google's aid at all. It calls into question whether certain people are committed to ideals and principles, or more inclined to take the "he's a [self-censored] but he's our [self-censored]" approach common in foreign policy (but not really in a values-based community).

Those who view themselves as advocates not only of open source but of free software (hey, @bkuhn) should certainly not have the attitude that software freedom only matters when someone actually sues...

I'm now going to do a post on what this approach here means with a view to proprietary loadable kernel modules, which is an example of the wide-ranging implications it might have if one supported Google's reprocessing and repurposing of raw kernel headers.

Proprietary loadable kernel modules -- did a post but it doesn't appear here

Posted Mar 21, 2011 6:41 UTC (Mon) by FlorianMueller (guest, #32048) [Link]

I just posted a comment on proprietary loadable kernel modules and it is actually online at http://lwn.net/Articles/434491/, but it doesn't seem to appear on the "Has Bionic stepped..." page. Maybe that's due to update cycles (hopefully not a bug in the forum software).

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 16:16 UTC (Mon) by martinfick (subscriber, #4455) [Link] (1 responses)

I don't quite agree. In many cases google is simply weakening copyright, that is always welcome in my book. Naturally by weakening copyright, they weaken copyleft too. Do not forget that without copyright, copyleft would be mostly unneeded. I realize that fighting patents and tivoization with the GPL3 would no longer be possible at all, but I doubt the GPL3 has been very effective at that anyway. Those 2 issues are likely better off fought by some other means, hopefully one as clever and effective as the GPL2 will be found eventually.

Has Bionic stepped over the GPL line?

Posted Mar 23, 2011 3:56 UTC (Wed) by b7j0c (guest, #27559) [Link]

??

without copyright there would be no copyleft

Proprietary loadable kernel modules

Posted Mar 21, 2011 6:35 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (24 responses)

I don't think I misunderstood Linus Torvalds. We're simply talking about two conflicting principles, both of which Linus Torvalds described clearly in the mail I quoted: on the one hand there's the normal syscall exception; on the other hand there are copyleft implications in connection with the use of source code files. Let me quote the two paragraphs from Linus Torvalds' mail that make this clear:

But that "use" [normal syscalls] is clearly limited to running the resultant program. It very much does NOT say that you can "use the header files in any way you want, including building non-GPL'd programs with them".
In fact, it very much says the reverse. If you use the source code to build a new program, the GPL _explicitly_ says that that new program has to be GPL'd too.

To me there is no doubt that by "the source code" he means "the header files" because that's the type of source code file at issue in this context and mentioned in the first of the two quoted paragraphs.

If I can take a source code file (albeit a header file) that comes with a clear copyright and GPL notice at the start and compile it into my program without creating a derivative work, what else would be a derivative work?

Of course one can also make a derivative work argument based on the specific functionality provided, meaning that the resultant setup (original code plus one's new extension) is an extended version of the original code. In Android's case, that would raise interesting questions since it's an operating system but built on Linux, which is an operating system kernel, so the question is whether from a functionality point of view we're talking about a fork.

Note that even LWN itself used the compilation of code against original (raw) kernel headers as an argument for LKMs constituting derivative works. In the second paragraph of this LWN article on proprietary kernel modules, Jon mentions that LKMs "require (GPL-licensed) header files to build" as one of several arguments for why they "should perhaps be seen as derived works".

In my understanding, LKMs need to be compiled against at least module.h, and in practical terms against more headers. If any of those headers could just be un-GPL'd the way Google claims it can un-GPL the raw headers for Bionic, there might still be other arguments remaining for which one can claim that LKMs are derived works, but one argument would be gone.

A similar argument as in Jon's article was also made by the Linux Documentation Project on this page.

One can hardly overstate the wide-ranging implications that it would have for the Linux kernel community and the entire GPL software universe if Google's approach to the raw kernel headers was condoned. I'm not sure every Google apologist has thought this through completely.

Proprietary loadable kernel modules

Posted Mar 21, 2011 7:20 UTC (Mon) by wahern (subscriber, #37304) [Link] (23 responses)

> In my understanding, LKMs need to be compiled against at
> least module.h, and in practical terms against more headers.
> If any of those headers could just be un-GPL'd the way Google
> claims it can un-GPL the raw headers for Bionic, there might
> still be other arguments remaining for which one can claim
> that LKMs are derived works, but one argument would be gone.

Indeed, that is the heart of the issue. A compiler similarly "strips" comments and normalizes code; and in no sense is a piece of code dependent on a comment, or on the amount of white space in a declaration or definition; those things are semantically meaningless in a source file. Google posits, therefore, that all those things with semantic meaning in those header files is not copyrightable.

If Google isn't violating the GPL, then neither would any company distributing closed-sourced binary modules built against kernel headers. At best they would be liable under some sort of contributory infringement theory, except a non-distributing end-user would have a license to use the GPLd work, so there would be no infringement to contribute to. Under Google's theory, the derivative-ness doesn't happen until being loaded into the kernel. (Because if the headers are not copyrightable, it implies that neither are the interfaces to which they're intended to be run against; in other words, that there are other potential non-infringing Linux clones that might load that module. So until it's actually loaded, it's not derivative.)

People's defense of Google here is baffling. It's one thing to critique lawyers' poor technical comprehension. It's another to defend a copyright theory which affects such a clear and momentous change in Free Software licensing.

Proprietary loadable kernel modules

Posted Mar 21, 2011 7:28 UTC (Mon) by viro (subscriber, #7872) [Link] (10 responses)

This is complete crap. Kernel module will be _UNABLE_ to stay within the subset of definitions that covers syscall-related constants and structs, to start with.

Proprietary loadable kernel modules

Posted Mar 21, 2011 8:35 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (6 responses)

@viro, you appear to be saying that a kernel module will need MORE definitions than the "subset of [them] that covers syscall-related constants and structs".

1) If that is so, does this mean you consider constants and structs potentially copyrightable?

2.1) If the answer to 1) is yes, please consider that Bionic contains approximately 750 files containing a total of approximately 2.5 megabytes of constants and structs (plus other material, but the bulk of it is constants and structs). At the start of each such file, Google claims that this is "no copyrightable material" and threw out any copyright and GPL notices found in the raw headers.

2.2) If the answer to 2) is no, of if you wish to add something anyway, please specify what your derivative work theory for a loadable kernel module would be.

Proprietary loadable kernel modules

Posted Mar 21, 2011 12:04 UTC (Mon) by dgm (subscriber, #49227) [Link]

It amuses me that you find very important for the argument that Alexander Viro considers that something is copyrightable or not. Instead you chose to obviate something that's much more interesting: his intention. Were he and the rest of kernel developers trying to prevent others from using those constants and structures in non-GPL code? I cannot speak for them, but my guess is that they were not.

Additionally, it's clear that, even in the case constants and structs were copyrightable, there's the special exception about the syscall interface. There's no such exception for kernel modules.

Proprietary loadable kernel modules

Posted Mar 23, 2011 23:28 UTC (Wed) by baldridgeec (guest, #55283) [Link] (4 responses)

I should probably keep my mouth shut, not being a kernel developer, but I have always understood a (non-GPL) loadable kernel module's ability to link to code as being governed by the "#define GPL" sections.

This obviously DOES NOT mean that they cannot have include files which also have text defining the GPLed interfaces (indeed, AFAIK most if not all proprietary LKMs simply #include the kernel's own header files.) It is the use of those interfaces in the code which determines the behavior of cc and ld, and determines whether the module is considered a derivative work for the purpose of license compliance.

That being said, I'm not sure why the question of LKM licensing is coming up anyway, since Bionic is a reimplementation of libc, not a module.

Proprietary loadable kernel modules

Posted Mar 24, 2011 13:07 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (3 responses)

That is the intent of the kernel hackers; whether the law agrees with this is quite another thing...

Proprietary loadable kernel modules

Posted Mar 24, 2011 14:04 UTC (Thu) by etienne (guest, #25256) [Link] (1 responses)

The intent of the kernel hackers is a bit like the intent of GCC developers when they say that the resulting executable is not a derived work of GCC, or the intent of word processors developers when they say the final document is fully owned by the author of said document.
If the law disagree that may have very high consequences.

Proprietary loadable kernel modules

Posted Mar 24, 2011 19:53 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

OK, perhaps I misspoke. What I meant is that the kernel gang considers stuff using userland interfaces OK under whatever licence you fancy (not in the sense that such code is "not derivative", but that that such use is allowed), while using kernel-internal interfaces (specially ones marked GPL-only) is strictly GPL. It might be that the law says that both uses create derivatives, in which case you are being given an explicit permission for userland while in-kernel use is strictly GPL-only because it is a derivative; or it might say neither does, in which case the whole discussion is moot.

Proprietary loadable kernel modules

Posted Mar 25, 2011 0:42 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

The stated intent of the kernel hackers (or anyone in a similar position) has a great deal of effect when they say that something is permitted. If Linus says "you're in the clear as long as you don't use anything within #define GPL", then he can be legally barred from turning around and suing somebody when they take him seriously. Even without a formal statement along those lines, officially designating some symbols as GPL only implies that the rest of the symbols may be used by non-GPL modules.

Proprietary loadable kernel modules

Posted Mar 21, 2011 8:49 UTC (Mon) by wahern (subscriber, #37304) [Link] (2 responses)

Right, and neither do Google's processed header files only produce definitions that cover syscall related constants and structs. Just because they excise everything guarded by __KERNEL__ doesn't mean they aren't capturing copyrightable code; similarly, just because something is guarded by __KERNEL__ doesn't mean it's copyrightable. The law says what's copyrightable, not the author; the author can only license--explicitly or impliedly--what he has copyright in.

Go through those files yourself, and then ask yourself if you would mind if such collections of your own code of similar complexity and expressiveness to be entirely without copyright protection.

http://android.git.kernel.org/?p=platform/bionic.git;a=tree;...

The point is that _some_ of the output of the processing may be copyrightable; *not* that _all_ of it is. There's significantly more there than the syscall descriptor number for the read system call.

So you have to ask yourself, is the convenience to Google worth the circumscription of copyright protection for copyleft works? Perhaps it is; but don't pretend that their legal theory doesn't have repercussions.

Proprietary loadable kernel modules

Posted Mar 21, 2011 10:59 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Uh, the kernel header files *are* a collection of (in part) viro's own code.

Proprietary loadable kernel modules

Posted Mar 21, 2011 11:41 UTC (Mon) by wahern (subscriber, #37304) [Link]

Yes, I realize that. I've been using Linux and programming since 1994. I know who's who.

I'm merely trying to impress upon people that if you look at the actual code outside of the __KERNEL__ defines; and the actual code inside of the __KERNEL__ defines; unless you can identify differences in the inherent expressiveness of that code without substantially relying on practical intentions about making it difficult to create derivative binary modules, then by asserting *all* of the code outside of those defines is not copyrightable, you're also asserting that much of the code inside of those defines is likewise not copyrightability.

These are important distinctions (or lack thereof), because there is no shortage of very well regarded copyright lawyers and judges who believe almost no source code or software should be copyrightable. And they believe that because of expressivity concerns. But I'm not making a slippery slope argument, merely trying to point out that the legal issue turns on expressivity. If you think that expressivity primarily turns on the prevalence of logical operators and conditional statements (i.e. what we consider to constitute the body of functions), then you're already down the wrong path. Those things principally describe process; as such, they are considered more often not matters of copyright but of patent; things generally regarded as mutually exclusive. As they aren't expressive elements per se, it would be imprudent to suggest that code which does not implicate them does not implicate copyrightability at all. That is, if you care about the enforcement of copyleft license covenants.

Proprietary loadable kernel modules

Posted Mar 21, 2011 8:42 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (9 responses)

It's not so hard to explain why people would fail to understand the significance of this. To understand it requires the combination of (i) a grasp of the issue (including the ability to understand that in certain contexts, uncertainty is bad enough even if there's no certainty for a bad hypothesis being true) _AND_ (ii) the ability to focus on an issue without thinking about possible sympathies for, or allegiances to, particular companies.

But again, there's a few vocal apologists and they are all quite weak. None of them has stood up to say that what Google does to those headers isn't infringing. So in a way they all agree with me :-)

Concerning LKMs, while one might try to come up with other derivative work theories, the use of copyrighted, GPL'd headers would of course be the best chance to prevail in court. All you would have to do then is request, in discovery, production of the source code of a proprietary LKM (in the US that's child's play, and even in Europe you could get to that point if you do it right). Then you prove that GPL'd material was part of the source code that was compiled, and you've won. Any other theories are far harder to prove, if they can work at all.

Proprietary loadable kernel modules

Posted Mar 21, 2011 9:53 UTC (Mon) by foom (subscriber, #14868) [Link] (4 responses)

> But again, there's a few vocal apologists and they are all quite weak. None of them has stood up to say that what Google does to those headers isn't infringing. So in a way they all agree with me :-)

If what google does is considered infringing, it'd be nice for someone to explain how it's different than what glibc does. Perhaps they're both infringing, then...

(unlikely)

Proprietary loadable kernel modules

Posted Mar 21, 2011 9:56 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (3 responses)

The differences are quite fundamental. glibc uses the "sanitized" headers provided by the kernel maintainers for the purpose of creating libraries. Google reprocesses and repurposes the "raw" (original, non-sanitized) kernel headers.

Proprietary loadable kernel modules

Posted Mar 21, 2011 11:01 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

So... what magic does the headers_install script perform to strip out copyright that the (very similar) script that Google provides omits to do? It would be trivial for Google to use the output of headers_install, and then all your doom-mongering would be for nothing (except to spread FUD, but that *of course* isn't your intention, oh no).

Proprietary loadable kernel modules

Posted Mar 21, 2011 11:05 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

One of the differences is that the output of headers_install is provided by the kernel maintainer for the purpose of integration into C libraries. That's different than just repurposing something else.

Your thinly-veiled FUD accusation is unwarranted. If it's (according to you) trivial for Google to use the output of headers_install, and if they do that in the future, everything's fine from my point of view. I'd love to see exactly that happen, and the sooner, the better. So the easier it is for them to do it, the better. Still I believe this must be done.

Proprietary loadable kernel modules

Posted Mar 21, 2011 12:44 UTC (Mon) by sorpigal (subscriber, #36106) [Link]

You're talking lawyer-magic here, not reality. Only in lawyer-magic-land does it matter whether they use the "raw" headers and then create their stripped version or use the headers_install version and then create their stripped version. Lawyers may think that there's a difference, but there isn't.

Proprietary loadable kernel modules

Posted Mar 21, 2011 21:33 UTC (Mon) by chrisV (guest, #43417) [Link] (3 responses)

"It's not so hard to explain why people would fail to understand the significance of this. To understand it requires ..."

Since you are neither a lawyer nor a kernel developer, to be perfectly frank your understanding probably doesn't mean very much.

Judging by the number of post you have made to this thread, you also have a significant amount of time on your hands, so you could consider using it to obtain a legal qualification.

Proprietary loadable kernel modules

Posted Apr 18, 2011 20:31 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

What? Florian's not even a lawyer? But he spouts off so much about other poeple (hello PJ) not being lawyers and therefore not being eligible to say a blessed thing...

*boggle*

Proprietary loadable kernel modules

Posted Apr 18, 2011 20:33 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

You miss the point here. I never said that non-lawyers are ineligible to talk about those matters. I pointed out that the avatar named "PJ" doesn't provide any background other than the status of "paralegal".

Proprietary loadable kernel modules

Posted May 9, 2011 11:12 UTC (Mon) by nix (subscriber, #2304) [Link]

Yes, you did. Over and over again. What you failed to indicate is why we should care at all, much less why we should consider her employment credentials more significant than the things she's done under the groklaw banner. "Florian does it" is not sufficient evidence.

Proprietary loadable kernel modules

Posted Mar 21, 2011 8:45 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

A compiler similarly "strips" comments and normalizes code; and in no sense is a piece of code dependent on a comment, or on the amount of white space in a declaration or definition; those things are semantically meaningless in a source file. Google posits, therefore, that all those things with semantic meaning in those header files is not copyrightable.

FULL ACK. Google's approach is that they harvest all the fruit from the trees and say only the remainder is copyrightable...

Proprietary loadable kernel modules

Posted Mar 24, 2011 21:17 UTC (Thu) by filipjoelsson (guest, #2622) [Link]

If you refer to the ABI when you write "all the fruit", then you are correct. Isolating the ABI is what the header laundering is all about. It's just that THE ABI IS EXPLICITLY NOT COVERED in the COPYING file!

I do not belong to the group who think you are spreading FUD, but that's just because I recognize that you are a troll.

Herrn Muller Again

Posted Mar 21, 2011 10:46 UTC (Mon) by brianomahoney (guest, #6206) [Link] (14 responses)

I re-iterate that, as soon as I hear the name Florian Muller, I know I am in for pages of long, boring and obscure comments, of the he said, she said variety.

I am sorry, it is about as interesting as two 7 year olds arguing in the school playground with out the other outcome, It will all be contrived self serving FUD.

I would normally be the first to defend freedom of speach but I for one have had more than a lifetimes worth of Muller's boring, rebarbative CRUD!

Herrn Muller Again

Posted Mar 21, 2011 10:49 UTC (Mon) by lkundrak (subscriber, #43452) [Link] (8 responses)

That's what's comment filtering for I guess.

Herrn Muller Again

Posted Mar 21, 2011 11:02 UTC (Mon) by brianomahoney (guest, #6206) [Link] (7 responses)

We shouldn't need to filter comments Muller should have more common sense and politeness NOT to do this FM please STFU

Herrn Muller Again

Posted Mar 21, 2011 11:07 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (3 responses)

@brianomahoney, you should re-read your own comment above with a derogatory four-letter word etc. and then ask yourself whether your "common sense and politeness" live up to your own standards.

Herrn Muller Again

Posted Mar 21, 2011 12:38 UTC (Mon) by brianomahoney (guest, #6206) [Link] (2 responses)

FlorianMueller,

At the expense of doing what you do, always trying to have the last word, that STFU is not normally considered a _bad_ word.

Your arguements as uniformly tendentious, often wrong, _but_ always boring and your need to have the last word is a real pain.

But I have hammered this one to death, hope you get the picture.

Herrn Muller Again

Posted Mar 21, 2011 12:45 UTC (Mon) by FlorianMueller (guest, #32048) [Link] (1 responses)

Interesting. STFU is above board for someone who demands politeness. How about CRUD, which you also used (and capitalized)?

Finally, in many cases people ask me questions and I answer them. I don't know what would be preferable -- ignoring or answering. In other cases I see misquotes, misinterpretations or misconceptions that relate to what I say. So I set the record straight in many (not all) of those cases.

You still haven't presented a good reason for not using filtering.

Herrn Muller Again

Posted Mar 22, 2011 5:44 UTC (Tue) by rahvin (guest, #16953) [Link]

Finally, in many cases people ask me questions and I answer them.
And in many cases you ignore the question or divert the answer away with supposition and innuendo.

Here's the question you keep ignoring: Exactly what is your motivation in this? It's been asked several times in different ways and you've ignored the question each time. You've attempted to stir up this tempest in a teapot and have yet to explain why this is so important that you feel the need to delve into legal examinations that you clearly don't understand and you continue to make statements about implied legal liability but have yet to cite single legal precedent in any jurisdiction. The worst part is this is the second "legal problem" with android you've attempted to expose and had it blow up as a non issue but only after it spread widely. The only logical conclusion, baring your own admission, is that you are spreading FUD for a reason that you won't reveal. The only reasons I can think of aren't very flattering to you, I doubt I'm alone in that.

Herrn Muller Again

Posted Mar 21, 2011 19:09 UTC (Mon) by tzafrir (subscriber, #11501) [Link] (2 responses)

brianomahoney, RTFM :-)

Herrn Muller Againn Tzafrir

Posted Mar 22, 2011 16:17 UTC (Tue) by brianomahoney (guest, #6206) [Link] (1 responses)

Tzafrir, I am sorry, I dont know of a manual which would contain str reasons for Florian spreading FUD. Do you?

Herrn Muller Againn Tzafrir

Posted Mar 23, 2011 23:32 UTC (Wed) by baldridgeec (guest, #55283) [Link]

Perhaps there should be an entry in missing(7) :)

Herrn Muller Again

Posted Mar 31, 2011 15:43 UTC (Thu) by farnz (subscriber, #17727) [Link] (4 responses)

Don't waste time complaining about LWN's poor editorial choices - vote with your wallet and stop subscribing.

It's becoming increasingly clear recently (the last couple of years or so) that LWN is not able to apply the sort of editorial control needed to keep the comments section useful, preferring instead to act as a forum for he said/she said argumentation as found on Slashdot. Maybe LWN should go back to running a "letters to the editor" section, and remove comments completely?

Herrn Muller Again

Posted Mar 31, 2011 16:15 UTC (Thu) by foom (subscriber, #14868) [Link] (3 responses)

But LWN doesn't implement editorial control over comments at all, only the articles. If you find only the article useful, and not the comments, it's surely rather easy to avoid reading the comments.

I, for one, find the comments overall quite interesting and useful, although there are certainly some particular topics for which they are less so.

Herrn Muller Again

Posted Apr 1, 2011 10:55 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

I found the articles and the letters to the editor useful - the clarifications and expansions in letters to the editor were adding value.

When comments were introduced, they also added value; the people who were writing the letters to the editor shifted to writing comments. Over time, people providing intelligent comments have been drowned out in favour of personal attacks and rants; as a nice side effect, you've ensured that I cannot safely send a Subscriber Link to my managers, because I will get pulled up on spending work time on a site that's so poorly managed if the comments happen to degenerate - and there's no way to predict which articles will do that.

I don't know what the solution is - if I did, I'd be e-mailing LWN with it again; I do know that the shift in SNR on LWN has meant I no longer find it worthwhile paying for access, and that comments that basically boil down to "guys, the SNR is low" don't help improve it. I can only hope that a gradual loss of income will convince Corbet et al to find a way to improve it.

»Managing« comments?

Posted Apr 1, 2011 11:21 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

I for one would much rather see Jon and his colleagues spend their time on producing quality editorial content than on policing comments. Presumably, people are here for the original content rather than the comments. Nobody is forced to read the comments, anyway, and there's even a way to get rid of the more obnoxious commenters.

I suppose if there is to be some sort of »management« of comments it will have to be »crowd-sourced« so as to not take time away from our esteemed journalists – this seems to call for a Slashdot-type up/downvoting system with a user-customisable threshold (so people who are here for the personal attacks and he-said-she-said can still get it if they want). Voting – or the use of this system altogether – could even be restricted to paying subscribers to make the subscriptions more attractive.

Other than that, it is up to us (the readership) to do our thing for comment quality, by posting considered and courteous comments and deliberately not engaging in flame wars with obvious trolls.

»Managing« comments?

Posted Apr 1, 2011 15:39 UTC (Fri) by farnz (subscriber, #17727) [Link]

I used to pay for the project leader level of subscription, in large part so that when an article relevant to my company appeared, I could send my management a link to it and not feel guilty. I can't stop my management looking at the comments - if you're not logged in (they don't even have accounts here), you have no comment filtering at all.

So, I'm afraid that those commenters who treat LWN's comments section as a place for personal attacks (I at least work somewhere where robust technical argument is understood) have destroyed my reason for paying for the site. A technical fix on LWN's part would be to provide me with a way of sending comments-free links, or links with my comment filtering applied (maybe something to offer for project leaders); then, at least, I could send my management links to interesting articles, knowing that they won't latch onto the flamewar in the comments section and chastise me.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 13:20 UTC (Mon) by nathan (subscriber, #3559) [Link] (13 responses)

'While glibc is not under the GPL, as it is licensed under the LGPL (v2 currently, with a plan to move it to v3)'

If the FSF change glibc's license thusly, I predict that:
*) linux distributions not already using eglibc will move to eglibc
*) there will be no further merges from glibc to eglibc

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 14:00 UTC (Mon) by foom (subscriber, #14868) [Link] (12 responses)

Right -- if glibc moves to LGPLv3, it becomes incompatible with GPLv2 licensed applications! That seems pretty unlikely to fly.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 16:46 UTC (Mon) by HelloWorld (guest, #56129) [Link] (11 responses)

> Right -- if glibc moves to LGPLv3, it becomes incompatible with GPLv2 licensed applications!
I'd like to see a reliable source for this assertion. It doesn't seem to make much sense, as the whole point of the LGPL is to allow GPL-incompatible software to link against an LGPL library.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 16:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

Refer to

http://fedoraproject.org/wiki/Licensing:Main#GPL_Compatib...

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 17:03 UTC (Mon) by HelloWorld (guest, #56129) [Link] (9 responses)

Thanks, I'm surprised to see this. Anyway, I don't think it applies here. In the GPLv2 it says
> However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
This exception clearly applies to glibc.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 18:03 UTC (Mon) by dark (guest, #8483) [Link] (8 responses)

This came up often on debian-legal :) There is an exception to the exception which makes it useless for most distributions: "unless that component itself accompanies the executable". If you're distributing glibc and the application together then the exception does not apply. Most distributions are in this position. The application developers will be able to release their application on their own site but they won't be able to get it into Debian. This is suboptimal.

I think the "exception to the exception" is vague

Posted Mar 21, 2011 18:49 UTC (Mon) by dbruce (guest, #57948) [Link] (7 responses)

"unless that component itself accompanies the executable"

How do you define "accompanies"? Does every (perhaps optional) package in Debian accompany every other package, all because they came out of the Debian archive? IANAL, but it seems to me to be a stretch to interpret this clause to mean that if GNU releases glibc under LGPL3, they are intending that it would not fall under the "system component" exception.

It seems more like a subtle bug in the wording of the LGPL3 than anything else.

Actually there are nothing vague about it...

Posted Mar 21, 2011 22:07 UTC (Mon) by khim (subscriber, #9252) [Link] (5 responses)

The "exception to exception" was designed to fight the following scenario: Microsoft or Sun takes GPLed program, stuffs all proprietary stuff in "system library" and then uses "system library" exception to sell such a combination. That's why Solaris usualy supplied GNU tools on separate "supplement" CD.

Now this protection backfires: GPLv3 takes a role of proprietary "system library" and so it can not be used for GLibC till everyone else will switch to GPLv3. Which probably will not happen anytime soon.

Actually there are nothing vague about it...

Posted Mar 21, 2011 22:17 UTC (Mon) by foom (subscriber, #14868) [Link] (4 responses)

> Which probably will not happen anytime soon.

I'd say, Which will not *ever* happen.

I'm not so sure...

Posted Mar 23, 2011 21:29 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

I'd say, Which will not *ever* happen.

I'm not so sure. Note that any non-trivial GPLv2-only program written in C++ can not be distributed on the same medium as GCC (remember that libgcc was relicensed under GPLv3+exception in GCC 4.4). BTW this includes older versions of KDE :-)...

About the only piece of code which can be forever kept under GPLv2 license is kernel (because it does not use standard GCC libraries and headers). Everything else is risky (you must prove code pulled from libgcc.a is uncopyrightable - and it's not always the case... especially on the platforms without FPU).

P.S. You can forever keep library and/or program under LGPL v2.x - but it's not a problem since it can then be linked with LGPLv3-licenses GLibC...

I'm not so sure...

Posted Mar 24, 2011 0:28 UTC (Thu) by foom (subscriber, #14868) [Link] (2 responses)

I don't think that's the case; can you point out the clause of the GCC Runtime Library Exception that you think restricts distribution on the same medium?

http://www.gnu.org/licenses/gcc-exception.html

It looks like it allows that, to me...

It's not the exception...

Posted Mar 24, 2011 7:00 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

I don't think that's the case; can you point out the clause of the GCC Runtime Library Exception that you think restricts distribution on the same medium?

It's not the exception. It's GPL v2, again. The same problem: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.. Independent GPLv2-only program is safe. But if you include GPLv2-only program and GCC on a single medium - you are violating GPLv2 (often, but not always: while libstdc++ is included in most C++ programs and indeed is complex and copyrightable libgcc is much simpler and on some platforms like x86 it does not put anything copyrightable in С program). I'll not play Microsoft Florian and claim it immediately spells "the end of the world": it's not enough to violate someone's copyright. That someone must sue your first or at least claim it's offended. And if he can easily decide that in reality he's not offended and actually wants to permit such redistribution (like MySQL did), but it's genuine license violation and so is landmine...

P.S. In reality it's not 100% true: in some countries it is possible to sue someone even if the copyright owner is not objecting and even win the case, we are talking about sane jurisdictions here.

It's not the exception...

Posted Mar 24, 2011 12:12 UTC (Thu) by foom (subscriber, #14868) [Link]

Er, duh, of course. I think my brain was off when I asked that. I remember now that LWN.net even covered the issue in an article I commented upon. :)

http://lwn.net/Articles/343608/

I think the "exception to the exception" is vague

Posted Mar 22, 2011 8:40 UTC (Tue) by dark (guest, #8483) [Link]

I would say they all accompany each other, after all they're in the same directory tree and even next to each other in the pool/ directories. Also, if someone makes a Debian DVD then they all end up on the same disc. (Well, not all, because they won't fit, but being unable to put the application on DVD#1 will mean it's incompatible with the DFSG anyway.)

As for the intent, this whole clause is there to allow GNU software to be used on proprietary systems, not the other way around. This was pretty important back when there were no free systems. I'd be hesitant to read it any other way.

In fact, if glibc were intended to fall under that clause with no exceptions, you would get the weird situation that it would be allowed for an otherwise-free distribution to include a glibc binary without source. (LGPL v2.1, clause 6). I doubt that is the FSF's intent.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 14:10 UTC (Mon) by viro (subscriber, #7872) [Link] (4 responses)

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?

Storm in a Teacup

Posted Mar 21, 2011 15:45 UTC (Mon) by jejb (subscriber, #6654) [Link] (3 responses)

Fortunately, most of the community (except Florian) manage to recognise a Microsoft troll when they see one:

http://www.networkworld.com/community/blog/lawyer-behind-...

Since the end result of a BSD licensed bionic is explicitly permitted by the Linux Kernel COPYING file, as Bradly Kuhn and others have pointed out, there's no real story here. (Well, except for one competitor trying to FUD another).

There is a technical question about whether the methods Google chose to use on the header files are the correct ones ... and it's an important one for compliance people to think about. However, practically, if anyone tried to take this to court, a judge would ask what the damages and remedy were. The damages are essentially zero (because the end result is permitted) and the remedy would likely be to go back and get the method right with possibly a wrist slap if the company in question hadn't tried to do the right thing (which likely wouldn't apply in the Google case because they had).

Storm in a Teacup

Posted Mar 21, 2011 17:33 UTC (Mon) by cladisch (✭ supporter ✭, #50193) [Link] (2 responses)

Fortunately, most of the community (except Florian)

He is not part of the community, he is a lobbyist.
He was paid to campaign against software patents, but that relationship ended.

… manage to recognise a Microsoft troll when they see one

As you can see by his posts, he is a Microsoft troll.

His contract has quite severe clauses against the connection to his employer becoming known, so when asked about this, has to resort to quite an amusing amount of tapdancing, as seen here: http://lwn.net/Articles/434587/

Storm in a Teacup

Posted Mar 22, 2011 7:02 UTC (Tue) by jwildeboer (guest, #55642) [Link] (1 responses)

BTW Linus has spoken - http://www.itworld.com/open-source/140916/android-sued-mi...

"It seems totally bogus. We've always made it very clear that the kernel system call interfaces do not in any way result in a derived work as per the GPL, and the kernel details are exported through the kernel headers to all the normal glibc interfaces too."

[...]

"Of course, we do have our own 'internal' headers too, and we have stuff that is meant to be relevant only for the kernel. But there would be no point for Google to even use those, since they are useless outside of the kernel, so I don't see what the whole brouhaha would be all about. Except if it's somebody politically motivated (or motivated by some need of attention)," he continued.

And if it's indeed attention that these parties want, Torvalds has a suggestion for that, as well.

"If it's some desperate cry for attention by somebody, I just wish those people would release their own sex tapes or something, rather than drag the Linux kernel into their sordid world," Torvalds concluded.

Storm in a Teacup

Posted Mar 22, 2011 10:13 UTC (Tue) by rsidd (subscriber, #2582) [Link]

Good heavens. Does Linus really want a Naughton-Mueller sex tape?

Oh well, I guess he's right: it would be preferable to their dragging Linux into their sordid worlds.

Has Bionic stepped over the GPL line?

Posted Mar 22, 2011 8:33 UTC (Tue) by k8to (guest, #15413) [Link] (1 responses)

-1 This discussion makes me sad.

Has Bionic stepped over the GPL line?

Posted Mar 22, 2011 12:46 UTC (Tue) by ballombe (subscriber, #9523) [Link]

Agreed. Bionic is released under a GPL-compatible license so this is a non-existent non-issue.

Has Bionic stepped over the GPL line?

Posted Mar 22, 2011 12:45 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (2 responses)

Perhaps the best way to get out of all this mess would be for the kernel folks to agree that the "cleansed for libc" header files are distributed under, say, the BSD license. AFAICS, this would be strictly in line with the 1993 decree from Linus, thus nobody should object kernel-side. For glibc-side (or other libcs), the BSD license should be liberal enough to be able to use it freely.

Yes, this would need some auditing of what files (and what content of them) does land in the cleansed set. And perhaps some restructuring would be needed (i.e., the kernel-internal files #include the userland ones and add the internal stuff), as I don't believe a script will be trusted to do the conversion (+ license change) on its own.

Has Bionic stepped over the GPL line?

Posted Mar 24, 2011 19:07 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

Perhaps the best way to get out of all this mess would be for the kernel folks to agree that

They can't. "Kernel folks" in this case means copyright holders of the kernel header files. It isn't feasible to find them all and get a new copyright license from them.

Contrary to appearances, neither Linus nor the kernel maintainers have the power to permit any particular copying/deriving of the kernel.

Has Bionic stepped over the GPL line?

Posted Mar 24, 2011 20:00 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

I didn't mean to imply it was easy, just the best way out. And the authors of the userland headers (at least the part that survives the non-glue removal) can't be that spread out, the gang of the usual suspects who have been hacking the kernel for almost two decades now surely wrote the inmensely overwhelming majority of this.

Has Bionic stepped over the GPL line?

Posted Mar 22, 2011 17:04 UTC (Tue) by brianomahoney (guest, #6206) [Link]

The best solution to this generic problem is not technical, or licence based, as all this stuff is reasonably well understood and changes here would not matter anyway.

What is going on here is that unscrupulous lawyers are making poorly supported claims in order to work up FUD, now in the mobile OS and apps market place, especially since Google has got great traction with Android ie Linux+Java. This has provoked a rush of actual, if very ill founded litigation from Oracle and others and has provoked the usual community storm in a teacup about licences, file striping and occasional packaging errors.

The upshot of this is that hardly any of this matters for two reasons resulting from Microsoft's earlier attempts at FUD (a) any business seriously planning to adopt Andriod will do its own legal due dilligence and make its decisions on its own lawyers reports, and (b) The Microsoft supported SCO trolling has made business managers much more aware of what was being done to them and why. Linux is now emplaced and well regarded in data centres, and the FUD fails.

For this reason, I would respectfully recommend to the community that it cease amplyfing the efforts of Trolls, FUDers and astroturfers and leave Muller in spleandid isolation.

Baseless accusations

Posted Mar 22, 2011 17:21 UTC (Tue) by job (guest, #670) [Link]

There's baseless accusations and then there's just plain crazy. Even glibc would break copyright according to their twisted logic.

Müller did a lot of good against software patents. It's sad to see him chase every bone his new master throws him. Somehow I sincerely hope it pays well.

Has Bionic stepped over the GPL line?

Posted Mar 23, 2011 7:18 UTC (Wed) by FlorianMueller (guest, #32048) [Link] (2 responses)

While this discussion here appears to have subsided for the most part, I wanted to post this quick update. Yesterday I published more evidence of Google's habit of GPL laundering in Android: BlueZ and ext4. The related headers are not part of the /include/ directory path like the headers that C libraries use. Google uniquely deprived those programs of their copyright/copyleft protection.

That blog post also links to a timeline that shows that GPL laundering is part of Google's modus operandi. They started in 2008 and do it all the time. The changelogs indicate this. And I'm sure other companies will now do this, too.

I also did an infographic that shows how Android-related intellectual property litigation has exploded since last year. There are now 37 Android-related intellectual property lawsuits. Those who claim that no one is going to assert IPRs in GPL'd software against Android should consider how litigious this environment undoubtedly is. Also, the huge number of Android-related patent lawsuits is in no small part due to Google's arrogant and reckless approach to other people's intellectual property rights, which takes us full circle back to the GPL laundering issue.

Has Bionic stepped over the GPL line?

Posted Mar 23, 2011 14:48 UTC (Wed) by paulj (subscriber, #341) [Link]

These seem to be part of a kernel interface to user-space which, according to Linux licence, is generally held to be a copyright boundary. So your claim there likely is baseless.

There is perhaps a more fundamental problem, in that Google have built their Java userspace bluetooth stack on top of BlueZ. They have insulated their userspace by plugging a DBus proxy/agent in between their software and BlueZ code. However, while this may reduce the technical API dependence of most of their code, the functional fact remains that their Bluetooth stack appears to be dependent on GPL software (outside of that accessed via the Linux userspace API).

My experience of legal advice at another large corporate, in a similarish situation, is that sticking IPC between your code and GPL code does not, of itself, do anything to affect whether or not your code derives from the GPL code.

However, if the BlueZ copyright holders are cool with it, then there's no problem - regardless of what anyone else thinks.

https://sites.google.com/a/android.com/opensource/project...

Has Bionic stepped over the GPL line?

Posted Mar 24, 2011 17:04 UTC (Thu) by butlerm (subscriber, #13312) [Link]

You can't launder something that isn't copyrightable in the first place. As ably explained by the court in Baystate v. Bentley Systems (1996), technical interfaces aren't legitimately protected by copyright.

Google could take the entire internal technical interface to the Linux kernel modulo substantive inline functions, rewrite it in any form by any means whatsoever, distribute it under any "license" they feel like, and probably be entirely in the clear, so far as the law of the United States is concerned.


Copyright © 2011, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds