Who's Behind the Google-Linux License Ruckus? 241
jfruhlinger writes "Yesterday, news broke that Android might have a Linux copyright problem, which would be big trouble for Google, already locked in an IP struggle with Oracle over the mobile platform. Blogger Brian Proffitt looks deeper into the alleged violations. He notes that, while it's possible that Google's on shaky ground, the motivations behind the news release are murky: the lawyer who outlined the violation is an ex-Microsoft hand, and the news was widely propagated by gadfly Florian Mueller, who's tangled with Google over patent issues in the past. Moreover, the alleged violations are in header files, and it's not clear that those are copyrightable; if they are, no actual copyright holders have come forward to complain."
Comment removed (Score:5, Interesting)
Re:He's still right in pointing it out (Score:4, Interesting)
This is just more FUD being generated by Microsoft's shills.
And though it's intended effect is to tarnish Google's image/brand consumers really don't give a shit. They're going to buy an Android phone if they want one despite any copyright issues or what could turn out to be platform propaganda.
I think this is W7P's first shot across Android bow.
Re:He's still right in pointing it out (Score:1, Interesting)
Hmm.. someone pointed out that this guy is a troll and I disagreed, but then I looked at another mobile story and saw similarly pro-Microsoft comments from this user.
Then I looked at his comment history. You'll see he consistently praises Microsoft products on articles (Microsoft Access, Visual Studio, Windows Phone). Sure a dedicated customer, but come on, this is Slashdot.. that's not very common.
Re:He's still right in pointing it out (Score:3, Interesting)
The only thing unsubstantiated here is your post. Anyone who has noticed his little /. ritual - posting within a minute of the story hitting the front page, and bringing up Microsoft even when it's unrelated to the topic - can easily associate all of his accounts. His posts are usually correct half the time - which is why people step out to defend him - but they always are (a) defending Microsoft at every turn, (b) criticizing any of Microsoft's competitors, or (c) defending corporate interests (such as anti-piracy movements).
It's SCO all over again (Score:0, Interesting)
Microsoft did the same thing after the Vista disaster. Throw mud on Linux so no one gets any big ideas about jumping off the MSFT treadmill.
Re:And Bionic is different from glibc how? (Score:4, Interesting)
What I gathered from the previous articles is that Bionic includes headers that are automatically generated from the Linux kernel headers with a statement added by Google that those generated headers contain no copyrightable material. What glibc does is compile against the unmodified Linux kernel headers, which must be present in some directory on the machine doing the build. So glibc includes the kernel headers by means of the C #include preprocessor directive, not by copying text fragments from them into the library package. I haven't looked at the Bionic sources, so I haven't verified this myself; it is based on statements in the articles.
What I wonder is why Google would not simply compile their libc against the Linux kernel source, like glibc does. That would avoid the legal uncertainty. Is there anyone familiar with the Android internals who can shed some light on this?
Re:No complaints? (Score:4, Interesting)
The topic of "shilling" etc is, hopefully, settled in the other thread.
However, I don't quite understand the applicability of the note you've quoted. From the wording, it sounds more like an attempt to disambiguate what "linking" is (or, more generally speaking, what a "derived work" is), in the context of userspace vs kernel. While the consensus has always been that apps written for an OS are not works derived from that OS, even though they directly or indirectly use its syscalls - even Stallman agrees on that, last I checked - the entire topic is rather hazy from a strictly legal perspective. After all, FSF says that dynamically linking to libraries does create a derived work for GPL purposes - and that is not fundamentally different from doing syscalls. In both cases, the client binary doesn't have any machine code derived from the source code of the library/kernel, but only calls with matching names & arguments.
A note like the one you quoted straightens it out: using normal system calls does not make a derived work, even if GPL itself could somehow be interpreted otherwise.
However, the note does not say anything about copyright on the headers. Re-reading the original article (the one before this), it seems that headers in question do actually have the GPL copyright notice in them. In this case, Google stripping that out is definitely wrong, because their process clearly creates a derived work (after all, it does take the original header as input, and applies purely mechanical transformations; I think this is clear cut). As the resulting derived work - the Bionic headers themselves - is not a "userspace binary" (it's not a binary at all!), the exclusion notice in COPYING does not apply to them. However, the notice prevents this from being "viral" - it basically says that userspace apps are not considered derived works by the authors of the kernel at all, regardless of anything else; and thus GPL (or rather copyright itself) simply does not apply.
So it seems to me that "everyone is violating GPL by writing closed-source Android apps" part is FUD, but Google still has some house cleaning to do here to be in the clear - either put the GPL copyright notice back into the headers (with an explanatory note as to why this does not apply to userspace programs including those headers), or else ask the kernel folk to grant them an exception.
Re:What Google is Really Doing Wrong (Score:2, Interesting)
OK, I know this is going to get voted way down as a troll attempt or something, but seriously--the real thing Google is doing wrong is using Linux. Since they want Android to be licensed as much as possible under more open licenses (they used Apache 2 for nearly all of their original code), they should have went with a BSD kernel. There's no real technical advantage to Linux over BSD in this kind of application, and it would sidestep all risk of this kind of potential license problem.
Same for all the various router manufacturers, set top box makers, TV makers, and so on that have run into GPL problems. I have no idea why no one has made something like BusyBox, but built around BSD and similarly licensed software.
If you have no idea why everybody else is doing something, you should find suspect perhaps they know something you don't.
In this case, there is a huge technical advantage to using Linux over BSD. Where to start? First, Linux has far, far more drivers for the hardware you need on mobile devices. And a lot more people know how to write such drivers, so it's far easier to hire someone to write a new one for you. Second, Linux has enormous resources poured into it from multiple corporations and independent contributors, far far more than any BSD variant. Linux therefore has more features and optimizations.
Note: I'm not hating on BSD. The BSDs are fine OSes, and there are problems for which they are a good solution. For example, if all you need is a super-secure server OS, a BSD might be right for you - it's simpler than Linux, some of the variants focus more on stability and security, and you probably won't run into hardware compatibility there. But for a mobile phone OS, there are very, very good reasons why Google, Palm, Nokia, Intel, etc. have all chosen Linux as the basis for their mobile OSes.
Re:And Bionic is different from glibc how? (Score:4, Interesting)
Now, this guy is a lawyer, and he understands copyright law more than me, but his understanding of this particular issue is weak. The example given earlier, of the bytewaps, does not apply at all to any developers on ARM because that was x86 specific code.
His second argument is extremely weak. He says the API is also copyrightable (which is sometimes true), and that if it were not, someone could use it to re-implement a closed source version of Linux. Which is true, but it's a rather braindead thing to worry about: getting the API is not the hardest part of that (and indeed, BSD has a linux compatibility layer that responds correctly to the Linux APIs).