Has Bionic stepped over the GPL line?
Ready to give LWN a try?With a subscription to LWN, you can stay current with what is happening in the Linux and free-software community and take advantage of subscriber-only site features. We are pleased to offer you a free trial subscription, no credit card required, so that you can see for yourself. Please, join us!
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:
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:
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:
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:
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.
Posted Mar 20, 2011 22:13 UTC (Sun)
by bkuhn (subscriber, #58642)
[Link] (36 responses)
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.
Posted Mar 21, 2011 6:11 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (18 responses)
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.
Posted Mar 21, 2011 6:18 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (17 responses)
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.
Posted Mar 21, 2011 9:36 UTC (Mon)
by foom (subscriber, #14868)
[Link] (15 responses)
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):
Posted Mar 21, 2011 10:47 UTC (Mon)
by rvfh (guest, #31018)
[Link]
Posted Mar 21, 2011 10:49 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (13 responses)
Posted Mar 21, 2011 11:41 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (12 responses)
1. we are not talking about random code files, but a very special case.
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?
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.
Posted Mar 21, 2011 12:01 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (8 responses)
Posted Mar 21, 2011 12:05 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (7 responses)
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. 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?
Posted Mar 21, 2011 14:33 UTC (Mon)
by drag (guest, #31333)
[Link] (6 responses)
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.
Posted Mar 21, 2011 14:43 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (5 responses)
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.
Posted Mar 21, 2011 15:53 UTC (Mon)
by drag (guest, #31333)
[Link] (1 responses)
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.
Posted Mar 21, 2011 19:48 UTC (Mon)
by foom (subscriber, #14868)
[Link]
+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...
Posted Mar 21, 2011 18:24 UTC (Mon)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Mar 21, 2011 18:29 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (1 responses)
Posted Mar 27, 2011 0:43 UTC (Sun)
by malor (guest, #2973)
[Link]
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.
Posted Mar 21, 2011 12:03 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
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.
Posted Mar 24, 2011 5:22 UTC (Thu)
by jtc (guest, #6246)
[Link]
"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.
Posted Apr 6, 2011 19:32 UTC (Wed)
by krakensden (guest, #72039)
[Link]
He's referencing a famous explanation of 'poisoning the well', a rhetorical strategy.
Posted Mar 21, 2011 9:20 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Posted Mar 21, 2011 14:36 UTC (Mon)
by vonbrand (guest, #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.
Posted Mar 21, 2011 14:52 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (2 responses)
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.
Posted Mar 21, 2011 16:35 UTC (Mon)
by vonbrand (guest, #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.
Posted Mar 24, 2011 5:27 UTC (Thu)
by jtc (guest, #6246)
[Link]
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."
Posted Mar 21, 2011 15:41 UTC (Mon)
by jubal (subscriber, #67202)
[Link] (7 responses)
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,
Posted Mar 21, 2011 16:06 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (5 responses)
Posted Mar 21, 2011 16:19 UTC (Mon)
by jubal (subscriber, #67202)
[Link]
Posted Mar 21, 2011 18:41 UTC (Mon)
by jonquark (guest, #45554)
[Link]
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.
Posted Mar 21, 2011 21:28 UTC (Mon)
by mdakin (guest, #42701)
[Link]
Posted Mar 21, 2011 23:37 UTC (Mon)
by clump (subscriber, #27801)
[Link]
Posted Mar 22, 2011 3:55 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
Posted Mar 22, 2011 12:01 UTC (Tue)
by michel (subscriber, #10186)
[Link]
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.
Posted Mar 21, 2011 19:26 UTC (Mon)
by vonbrand (guest, #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.
Posted Mar 21, 2011 21:14 UTC (Mon)
by clump (subscriber, #27801)
[Link]
Posted Mar 22, 2011 11:26 UTC (Tue)
by Seegras (guest, #20463)
[Link]
Posted Mar 20, 2011 22:29 UTC (Sun)
by vonbrand (guest, #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).
Posted Mar 21, 2011 5:22 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (3 responses)
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?
Posted Mar 21, 2011 6:12 UTC (Mon)
by jmm82 (guest, #59425)
[Link]
On Fri, 5 Dec 2003, Kendall Bennett wrote:
This was indeed one of the worries that people had a long time ago, and is
So I agree with you from a technical standpoint, and I claim that the
But at the same time I do want to say that I discourage use of the kernel
Posted Mar 21, 2011 6:43 UTC (Mon)
by viro (subscriber, #7872)
[Link]
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.
Posted Mar 21, 2011 14:55 UTC (Mon)
by vonbrand (guest, #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?
Posted Mar 20, 2011 22:55 UTC (Sun)
by jmm82 (guest, #59425)
[Link] (16 responses)
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?
Posted Mar 20, 2011 23:03 UTC (Sun)
by jake (editor, #205)
[Link] (15 responses)
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
Posted Mar 21, 2011 0:42 UTC (Mon)
by jmm82 (guest, #59425)
[Link] (14 responses)
"Who has the power to enforce the GPL?
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.
Posted Mar 21, 2011 1:45 UTC (Mon)
by corbet (editor, #1)
[Link] (4 responses)
Posted Mar 21, 2011 5:33 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (2 responses)
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)
Posted Mar 21, 2011 18:33 UTC (Mon)
by rahvin (guest, #16953)
[Link] (1 responses)
Posted Apr 2, 2011 5:54 UTC (Sat)
by Duncan (guest, #6647)
[Link]
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
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
Posted Mar 21, 2011 14:08 UTC (Mon)
by spaetz (guest, #32870)
[Link]
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 :-).
Posted Mar 21, 2011 2:23 UTC (Mon)
by wahern (subscriber, #37304)
[Link]
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.
Posted Mar 21, 2011 2:32 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (1 responses)
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.
Posted Mar 21, 2011 5:37 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link]
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.
Posted Mar 21, 2011 2:50 UTC (Mon)
by rgmoore (✭ supporter ✭, #75)
[Link] (5 responses)
#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.
Posted Mar 21, 2011 3:00 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
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.
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.)
Posted Mar 21, 2011 18:39 UTC (Mon)
by rahvin (guest, #16953)
[Link]
Posted Mar 23, 2011 17:26 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link]
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.
Posted Mar 21, 2011 9:39 UTC (Mon)
by ekj (guest, #1524)
[Link]
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.
Posted Mar 20, 2011 23:05 UTC (Sun)
by ewan (subscriber, #5533)
[Link] (7 responses)
Posted Mar 20, 2011 23:08 UTC (Sun)
by vonbrand (guest, #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.
Posted Mar 21, 2011 0:02 UTC (Mon)
by AndreE (guest, #60148)
[Link]
Posted Mar 21, 2011 0:32 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (3 responses)
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...
Posted Mar 21, 2011 0:38 UTC (Mon)
by swetland (guest, #63414)
[Link] (2 responses)
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
Posted Mar 21, 2011 4:19 UTC (Mon)
by b7j0c (guest, #27559)
[Link] (1 responses)
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?
Posted Mar 21, 2011 4:41 UTC (Mon)
by swetland (guest, #63414)
[Link]
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
Posted Mar 21, 2011 0:42 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 20, 2011 23:05 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 21, 2011 0:25 UTC (Mon)
by ras (subscriber, #33059)
[Link]
Posted Mar 21, 2011 0:46 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (51 responses)
Posted Mar 21, 2011 1:47 UTC (Mon)
by corbet (editor, #1)
[Link] (48 responses)
Posted Mar 21, 2011 2:30 UTC (Mon)
by vonbrand (guest, #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!
Posted Mar 21, 2011 2:43 UTC (Mon)
by tseaver (guest, #1544)
[Link] (36 responses)
Posted Mar 21, 2011 4:14 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (34 responses)
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.
Posted Mar 21, 2011 4:59 UTC (Mon)
by sfeam (subscriber, #2841)
[Link] (5 responses)
Posted Mar 21, 2011 6:00 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (4 responses)
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
Posted Mar 21, 2011 6:17 UTC (Mon)
by wahern (subscriber, #37304)
[Link]
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.
Posted Mar 21, 2011 18:33 UTC (Mon)
by butlerm (subscriber, #13312)
[Link] (2 responses)
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.
Posted Mar 24, 2011 6:49 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
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).
Posted Mar 24, 2011 16:24 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
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.
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.
Posted Mar 21, 2011 6:46 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (25 responses)
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.
Posted Mar 21, 2011 9:51 UTC (Mon)
by foom (subscriber, #14868)
[Link] (20 responses)
Posted Mar 21, 2011 12:25 UTC (Mon)
by dank (guest, #1865)
[Link] (19 responses)
Let's examine the resulting headers to see how close Google came to this,
I looked at one file,
CONFIG_EXT3_INDEX is not unreferenced anywhere (see
ext3_debug is only referenced inside the kernel, and is defined by
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
(Hi, Florian! Are you the same Florian I knew at Knowledge Adventure?)
Posted Mar 21, 2011 14:42 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (18 responses)
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.
Posted Mar 21, 2011 15:31 UTC (Mon)
by dank (guest, #1865)
[Link] (16 responses)
0) Semantic information needed for userspace (libc or apps) to interoperate
1) The expression of that information in a particular header is copyrightable
2) A compiler or other semantic analyzer can extract the noncopyrightable
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
6) Semantic information needed for kernel modules to interoperate
Posted Mar 21, 2011 15:34 UTC (Mon)
by wingo (guest, #26929)
[Link] (15 responses)
This doesn't sound right; otherwise one would be able to do the same for source files as well.
Posted Mar 21, 2011 16:14 UTC (Mon)
by dank (guest, #1865)
[Link] (14 responses)
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.
Posted Mar 22, 2011 3:52 UTC (Tue)
by wahern (subscriber, #37304)
[Link] (13 responses)
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.
Posted Mar 22, 2011 4:13 UTC (Tue)
by dank (guest, #1865)
[Link] (5 responses)
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...):
So there y'go. It's different because Linus said it is.
Posted Mar 22, 2011 14:23 UTC (Tue)
by wahern (subscriber, #37304)
[Link] (4 responses)
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.
Posted Mar 22, 2011 14:59 UTC (Tue)
by viro (subscriber, #7872)
[Link] (2 responses)
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...
Posted Mar 22, 2011 16:42 UTC (Tue)
by wahern (subscriber, #37304)
[Link] (1 responses)
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.
Posted Mar 22, 2011 16:53 UTC (Tue)
by wahern (subscriber, #37304)
[Link]
I respond only to protect my name; what with archiving and all. I'm not returning to this thread for the foreseeable future.
Posted Mar 22, 2011 15:52 UTC (Tue)
by sfeam (subscriber, #2841)
[Link]
Posted Mar 22, 2011 4:40 UTC (Tue)
by swetland (guest, #63414)
[Link]
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.
Posted Mar 22, 2011 12:28 UTC (Tue)
by ekj (guest, #1524)
[Link] (3 responses)
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.
Posted Mar 22, 2011 14:09 UTC (Tue)
by wahern (subscriber, #37304)
[Link] (2 responses)
Posted Mar 23, 2011 8:18 UTC (Wed)
by ekj (guest, #1524)
[Link] (1 responses)
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.
Posted Mar 23, 2011 19:26 UTC (Wed)
by martinfick (subscriber, #4455)
[Link]
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.
Posted Mar 22, 2011 14:43 UTC (Tue)
by foom (subscriber, #14868)
[Link]
Posted Mar 23, 2011 21:06 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link]
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.
Posted Mar 21, 2011 16:03 UTC (Mon)
by vonbrand (guest, #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.
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:
Posted Mar 21, 2011 14:29 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (2 responses)
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 ;)
Posted Mar 21, 2011 18:51 UTC (Mon)
by butlerm (subscriber, #13312)
[Link]
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.
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:
=====
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
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.
Posted Mar 21, 2011 15:04 UTC (Mon)
by vonbrand (guest, #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.
Posted Mar 21, 2011 12:53 UTC (Mon)
by corbet (editor, #1)
[Link]
Posted Mar 21, 2011 4:18 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (7 responses)
(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?)
Posted Mar 21, 2011 5:48 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (2 responses)
Posted Mar 21, 2011 6:20 UTC (Mon)
by jmm82 (guest, #59425)
[Link] (1 responses)
Posted Mar 21, 2011 10:57 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Mar 21, 2011 6:35 UTC (Mon)
by bronson (subscriber, #4806)
[Link] (2 responses)
Posted Mar 21, 2011 7:01 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Mar 21, 2011 8:47 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link]
Posted Mar 21, 2011 9:27 UTC (Mon)
by jzbiciak (guest, #5246)
[Link]
Posted Mar 21, 2011 5:50 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link]
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.
Posted Apr 7, 2011 16:14 UTC (Thu)
by stevem (subscriber, #1512)
[Link]
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?
Posted Mar 21, 2011 5:42 UTC (Mon)
by eru (subscriber, #2753)
[Link] (1 responses)
Posted Mar 21, 2011 10:58 UTC (Mon)
by brianomahoney (guest, #6206)
[Link]
Posted Mar 21, 2011 4:40 UTC (Mon)
by b7j0c (guest, #27559)
[Link] (4 responses)
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.
Posted Mar 21, 2011 5:59 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (1 responses)
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.
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).
Posted Mar 21, 2011 16:16 UTC (Mon)
by martinfick (subscriber, #4455)
[Link] (1 responses)
Posted Mar 23, 2011 3:56 UTC (Wed)
by b7j0c (guest, #27559)
[Link]
without copyright there would be no copyleft
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: 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.
Posted Mar 21, 2011 7:20 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (23 responses)
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.
Posted Mar 21, 2011 7:28 UTC (Mon)
by viro (subscriber, #7872)
[Link] (10 responses)
Posted Mar 21, 2011 8:35 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (6 responses)
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.
Posted Mar 21, 2011 12:04 UTC (Mon)
by dgm (subscriber, #49227)
[Link]
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.
Posted Mar 23, 2011 23:28 UTC (Wed)
by baldridgeec (guest, #55283)
[Link] (4 responses)
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.
Posted Mar 24, 2011 13:07 UTC (Thu)
by vonbrand (guest, #4458)
[Link] (3 responses)
That is the intent of the kernel hackers; whether the law agrees with this is quite another thing...
Posted Mar 24, 2011 14:04 UTC (Thu)
by etienne (guest, #25256)
[Link] (1 responses)
Posted Mar 24, 2011 19:53 UTC (Thu)
by vonbrand (guest, #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.
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
Posted Mar 21, 2011 8:49 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (2 responses)
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.
Posted Mar 21, 2011 10:59 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Mar 21, 2011 11:41 UTC (Mon)
by wahern (subscriber, #37304)
[Link]
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.
Posted Mar 21, 2011 8:42 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (9 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 :-)
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.
Posted Mar 21, 2011 9:53 UTC (Mon)
by foom (subscriber, #14868)
[Link] (4 responses)
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)
Posted Mar 21, 2011 9:56 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (3 responses)
Posted Mar 21, 2011 11:01 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Mar 21, 2011 11:05 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (1 responses)
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.
Posted Mar 21, 2011 12:44 UTC (Mon)
by sorpigal (guest, #36106)
[Link]
Posted Mar 21, 2011 21:33 UTC (Mon)
by chrisV (guest, #43417)
[Link] (3 responses)
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.
Posted Apr 18, 2011 20:31 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
*boggle*
Posted Apr 18, 2011 20:33 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (1 responses)
Posted May 9, 2011 11:12 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Mar 21, 2011 8:45 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (1 responses)
FULL ACK. Google's approach is that they harvest all the fruit from the trees and say only the remainder is copyrightable...
Posted Mar 24, 2011 21:17 UTC (Thu)
by filipjoelsson (guest, #2622)
[Link]
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.
Posted Mar 21, 2011 10:46 UTC (Mon)
by brianomahoney (guest, #6206)
[Link] (14 responses)
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!
Posted Mar 21, 2011 10:49 UTC (Mon)
by lkundrak (subscriber, #43452)
[Link] (8 responses)
Posted Mar 21, 2011 11:02 UTC (Mon)
by brianomahoney (guest, #6206)
[Link] (7 responses)
Posted Mar 21, 2011 11:07 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (3 responses)
Posted Mar 21, 2011 12:38 UTC (Mon)
by brianomahoney (guest, #6206)
[Link] (2 responses)
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.
Posted Mar 21, 2011 12:45 UTC (Mon)
by FlorianMueller (guest, #32048)
[Link] (1 responses)
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.
Posted Mar 22, 2011 5:44 UTC (Tue)
by rahvin (guest, #16953)
[Link]
Posted Mar 21, 2011 19:09 UTC (Mon)
by tzafrir (subscriber, #11501)
[Link] (2 responses)
Posted Mar 22, 2011 16:17 UTC (Tue)
by brianomahoney (guest, #6206)
[Link] (1 responses)
Posted Mar 23, 2011 23:32 UTC (Wed)
by baldridgeec (guest, #55283)
[Link]
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?
Posted Mar 31, 2011 16:15 UTC (Thu)
by foom (subscriber, #14868)
[Link] (3 responses)
I, for one, find the comments overall quite interesting and useful, although there are certainly some particular topics for which they are less so.
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.
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.
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.
Posted Mar 21, 2011 13:20 UTC (Mon)
by nathan (subscriber, #3559)
[Link] (13 responses)
If the FSF change glibc's license thusly, I predict that:
Posted Mar 21, 2011 14:00 UTC (Mon)
by foom (subscriber, #14868)
[Link] (12 responses)
Posted Mar 21, 2011 16:46 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (11 responses)
Posted Mar 21, 2011 16:48 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (10 responses)
Posted Mar 21, 2011 17:03 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (9 responses)
Posted Mar 21, 2011 18:03 UTC (Mon)
by dark (guest, #8483)
[Link] (8 responses)
Posted Mar 21, 2011 18:49 UTC (Mon)
by dbruce (guest, #57948)
[Link] (7 responses)
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.
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.
Posted Mar 21, 2011 22:17 UTC (Mon)
by foom (subscriber, #14868)
[Link] (4 responses)
I'd say, Which will not *ever* happen.
Posted Mar 23, 2011 21:29 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
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...
Posted Mar 24, 2011 0:28 UTC (Thu)
by foom (subscriber, #14868)
[Link] (2 responses)
http://www.gnu.org/licenses/gcc-exception.html
It looks like it allows that, to me...
Posted Mar 24, 2011 7:00 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
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.
Posted Mar 24, 2011 12:12 UTC (Thu)
by foom (subscriber, #14868)
[Link]
Posted Mar 22, 2011 8:40 UTC (Tue)
by dark (guest, #8483)
[Link]
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.
Posted Mar 21, 2011 14:10 UTC (Mon)
by viro (subscriber, #7872)
[Link] (4 responses)
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.
Posted Mar 21, 2011 16:04 UTC (Mon)
by jwildeboer (guest, #55642)
[Link]
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)
Posted Mar 21, 2011 16:23 UTC (Mon)
by swetland (guest, #63414)
[Link] (1 responses)
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.
Posted Mar 21, 2011 17:01 UTC (Mon)
by viro (subscriber, #7872)
[Link]
Posted Mar 25, 2011 22:53 UTC (Fri)
by ccurtis (guest, #49713)
[Link]
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?
Posted Mar 21, 2011 15:45 UTC (Mon)
by jejb (subscriber, #6654)
[Link] (3 responses)
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).
Posted Mar 21, 2011 17:33 UTC (Mon)
by cladisch (✭ supporter ✭, #50193)
[Link] (2 responses)
He is not part of the community, he is a lobbyist. 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/
Posted Mar 22, 2011 7:02 UTC (Tue)
by jwildeboer (guest, #55642)
[Link] (1 responses)
"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.
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.
Posted Mar 22, 2011 8:33 UTC (Tue)
by k8to (guest, #15413)
[Link] (1 responses)
Posted Mar 22, 2011 12:46 UTC (Tue)
by ballombe (subscriber, #9523)
[Link]
Posted Mar 22, 2011 12:45 UTC (Tue)
by vonbrand (guest, #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.
Posted Mar 24, 2011 19:07 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (1 responses)
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.
Posted Mar 24, 2011 20:00 UTC (Thu)
by vonbrand (guest, #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.
Posted Mar 22, 2011 17:04 UTC (Tue)
by brianomahoney (guest, #6206)
[Link]
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.
Posted Mar 22, 2011 17:21 UTC (Tue)
by job (guest, #670)
[Link]
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.
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.
Posted Mar 23, 2011 14:48 UTC (Wed)
by paulj (subscriber, #341)
[Link]
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...
Posted Mar 24, 2011 17:04 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
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.
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.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
"So far I haven't seen any other expert claim that there isn't an infringement"
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/036...
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
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.
Naughton didn't do enough research to justify his conclusions.
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.
Naughton didn't do enough research to justify his conclusions.
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.
All anyone can reasonably do is fix problems once they are alerted. [...] But you, sir, have not demonstrated ANY problem that needs fixing
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
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.
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.Naughton didn't do enough research to justify his conclusions.
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.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
"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.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
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.
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.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
Naughton didn't do enough research to justify his conclusions.
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?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
>
> Right, and by extension of the same argument you cannot use kernel
> headers to create non-GPL'ed binaries that run IN USER SPACE!
one (but only one) of the reasons for the addition of the clarification to
the COPYING file for the kernel.
clarification in COPYING about user space usage through normal system
calls covers that special case.
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?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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 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?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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.
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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!
Has Bionic stepped over the GPL line?
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.
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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.
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?
The interesting claim seems to be this one:Has Bionic stepped over the GPL line?
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?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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?
Has Bionic stepped over the GPL line?
What's the point of this article?
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?
What's the point of this article?
You, go, Jon!
You, go, Jon!
You, go, Jon!
You, go, Jon!
You, go, Jon!
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.)
You, go, Jon!
You, go, Jon!
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?
You, go, Jon!
What Google's actually doing
What Google's actually doing
What Google's actually doing
Google should strip out unreferenced symbols... but it probably doesn't matter
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).
and see if we can find particular lines that are not forced by the kernel ABI.
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:
http://lxr.e2g.org/ident?i=CONFIG_EXT3_INDEX )
the unstripped kernel headers (see
http://lxr.e2g.org/ident?i=ext3_debug )
headers that are not referenced by bionic, but since they're not
referenced, no actual harm has been done.
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
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
semantic information from a copyrighted header and dump it to a new sanitized header without infringing the header's copyright
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.
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
> semantic information from a copyrighted header and dump it to a new
> sanitized header without infringing the header's copyright
Google should strip out unreferenced symbols... but it probably doesn't matter
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
See http://lwn.net/Articles/244375/
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
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...
"If you use standard UNIX system calls (with accepted Linux extensions), your program obviously doesn't "derive" from the kernel itself."
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
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
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
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.
Google should strip out unreferenced symbols... but it probably doesn't matter
Google should strip out unreferenced symbols... but it probably doesn't matter
Either they both are, or neither. Whatever it is that makes one copyrightable also makes the other copyrightable; they rise and fall together.
Google should strip out unreferenced symbols... but it probably doesn't matter
What Google's actually doing
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
If that is indeed the case[...], than how can copyright prevent distribution of binary modules built against those headers?
What Google's actually doing
What Google's actually doing and Kernel modules proper
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?
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.
You, go, Jon!
Glad you like it - but do note that Jake wrote this article, not me.
You, go, Jake!
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
What's the point of this article?
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
This is the point of this article
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
i'm not entirely sure why the open source community continues to rally to google's defense
Proprietary loadable kernel modules -- did a post but it doesn't appear here
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Proprietary loadable kernel modules
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.Proprietary loadable kernel modules
> 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.
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
If the law disagree that may have very high consequences.
Proprietary loadable kernel modules
Proprietary loadable kernel modules
#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
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
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
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
Proprietary loadable kernel modules
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.
Proprietary loadable kernel modules
Herrn Muller Again
Herrn Muller Again
Herrn Muller Again
Herrn Muller Again
Herrn Muller Again
Herrn Muller Again
Herrn Muller Again
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
Herrn Muller Againn Tzafrir
Herrn Muller Againn Tzafrir
Herrn Muller Again
Herrn Muller Again
Herrn Muller Again
»Managing« comments?
»Managing« comments?
Has Bionic stepped over the GPL line?
*) 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?
Has Bionic stepped over the GPL line?
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?
Has Bionic stepped over the GPL line?
> 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.
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.
Has Bionic stepped over the GPL line?
I think the "exception to the exception" is vague
Actually there are nothing vague about it...
Actually there are nothing vague about it...
I'm not so sure...
I'd say, Which will not *ever* happen.
I'm not so sure...
It's not the exception...
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...
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.)
I think the "exception to the exception" is vague
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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?
Storm in a Teacup
Storm in a Teacup
Fortunately, most of the community (except Florian)
He was paid to campaign against software patents, but that relationship ended.
manage to recognise a Microsoft troll when they see one
Storm in a Teacup
Storm in a Teacup
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Perhaps the best way to get out of all this mess would be for the kernel
folks to agree that
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
Baseless accusations
Has Bionic stepped over the GPL line?
Has Bionic stepped over the GPL line?
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.
Has Bionic stepped over the GPL line?