Is the concern about android apps entirely well founded? It's not as if every linux app in the world has to be gpl-ed, despite the kernel being licensed under the GPL.
And how directly do android apps use kernel headers ? I wouldn't have though a userland application would need to mess with kernel headers (especially if written in java)
They are not "kernel headers." They *were* kernel headers that were slightly modified for user-land use. As explained in the linked legal analyses, this is the same thing that all Linux distros do, except that they keep the GPLv2 notice intact.
Will this really affect most Android developers?
Setting aside the matter of Google's probably questionable GPL to BSD Linux conversion, most Android developers don't extend the kernel directly. They instead use language libraries like Java and the GNU standard C and C++ libraries, which contain explicit GPL exceptions that allow the creation of proprietary software.
I think that only Android kernel module authors and similar developers, surely a small set, would be affected.
It's better explained on the article
but in summary the standard C library provided by Google (the Bionic library) contains the GPLed files. So yes any application linking to this could be affected.
Lol this is what you get with this crappy free open source shizzle. Time to watch the developers flock to Win Pho 7 where they know they are safe. Microsoft know how to treat developers and keep them safe. Simples
Microsoft equals Windows creator. Google is not the creator of Linux, but user/abuser of it.
There are free, open source apps made available for flavors of Windows, too, are they shizzle?
How does MS treat devs? How many devs have written apps for Windows that suddenly have a MS developed "duplicate" added straight into the operating system which hurt/killed their business? Browser, games, AV, media player, etc.?
get back under yer bridge!
"At issue are the header files in the Linux kernel - a list of APIs and macros that are used during compilation. These fall under the GPLv2 which states that any work derived from them must also be published under the GPLv2, but Google uses scripts to take out all the comments and extraneous odds and sods, then claims that this removes the copyright. That enables Google to publish the resulting code under the (less open) Apache licence as though it were an original work."
Apache is actually more open. Essentially under Apache you can do whatever you want with the code as long as you keep the attributions.
The key here is that Google's interpretation is not only wrong but dangerous.
Google is attempting to circumvent GPL2 by saying that by removing the non-functioning comments and headers that they are removing the copyright. That their code is no longer considered a derivative work. That is plain wrong and any lawyer who gave them an opinion to the contrary should be disbarred.
I would suggest that the FOSS community isn't up in arms because they didn't know this was happening.
As to the author's suggestion that now third party code could be adversely affected, the answer is a resounding *MAYBE**IT DEPENDS*. That is to say.. if you wrote some code that extends the code provided by Google and relied upon their assurances that the code was released under Apache's license, then you would have to change this to GPL and that means that you would be responsible for exposing your code to the public. This won't affect anyone who uses the APIs but only those who extended them.
The flame isn't for El Reg, or the Author, but for Google.
IMHO its tactics like this that make me believe that Google will also fail in Oracle's lawsuit too.
FOSS Community Reaction
The community reaction you describe is (a) not from the community buy a lawyer and (b) a bit late in the day seeing as Android has been available as source for quite some time now - certainly a good year.
In that time there have been several forks of Android, most of which have ended up coming back together under the Cyanogen(mod) banner, and all without as much as a murmur. I would expect that more than one Kernel man would have cast their eye over the code in the intervening period... if only to see what the folks at Google have done.
I'm happy to concede that some people (mainly Google) may have something to worry about. However I'm more inclined to think that the deafening silence that has ensued right up until Oracle started throwing their toys out of the pram implies that it suits somebody to make as much noise as they can about license violations... I wonder who that might be?
Don't forget that Google has been working to streamline their own extensions to the kernel and get them folded back into the main source tree. How could that go on for so long and nobody raise a concern about the kernel headers?
I would suggest the FOSS community isn't up in arms because those that looked at what Google had done though, "well, it isn't so different to any other fork". They might not have been aware of the mechanism used to get there.
I'm not saying Google are right, either. We all have a duty to ensure we remain within the terms of a license, or avoid the license altogether. If Google had the option of taking a well-established route that avoided an obvious pitfall, more fool them for not taking it.
Most people in the 'FOSS' community use the code and don't really look at the copyright and headers. Meaning they are coders and not lawyers.
Once outed don't be surprised to see the EFF come out against Google for violating the GPL.
Its not a fork.
Google has repeatedly taken short cuts and they are now going to get bit in the ass over it.
re: Apache is actually more open
No it's not, it's more liberal in that it allows you to use it in your own closed product. The rest of your post is good sense though.
Is Apache license more or less open the GPLv2,
as in the phrase "to publish the resulting code under the (less open) Apache license", is open to interpretation. One might argue that Apache license is less open because it allows closed source derivative works; I prefer to think that it is more open because it imposes less restrictions on the developer who builds upon Apache licensed code.
As to the removal of the copyright notices from the header files, this move sounds strange of course, but I would think that this is some kind of "legal hack" to legitimize the practice that everyone is engaged in anyway. There are lots of closed source applications running on Linux (think Oracle database, for instance); nearly all of them had to be compiled with #inclusion (indirectly in most cases) of Linux header files. This has never caused any legal trouble, or even a grudge from the open source developers. So, Google's move does not change established practice in any way.
Read the article?
This is about how Google took GPLed kernel header files and essentially created their libc from it. Applications linking this Google library will then also become GPLed.
The Linux C library is LGPL so applications can link to it without becoming themselves GPLed.
As for the applications including and using the Linux kernel, Linus makes a specific exception for them in the COPYING file of the kernel source tree:
"NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work"
So Oracle etc are all fine.
We need a icon with a longer beard.
There is no viral effect
"This is about how Google took GPLed kernel header files and essentially created their libc from it. Applications linking this Google library will then also become GPLed."
No they will not. Distributing the GPL-violating library would certainly be a copyright violation, but no such automatic viral effect exists. This is a pretty common misunderstanding. So, there is no obligation for 3rd party developers to make their source code available, either.
Sounds like a great plan then: open discardable company A which copies all code from GPLed project. open anther company B that uses the code. Company A found to be infringing, declare insolvency. Company B continues to sell on product without any problems. Profit!
Problem is, it just doesn't work like that. Both products would be infringing.
"Problem is, it just doesn't work like that. Both products would be infringing."
Yes, they might both be infringing, but still, that does not cause the 3rd party components to suddenly fall under GPL, forcing the developers to release the source. Of course the 3rd party developers might have to relicense the component under GPL if they wish to continue distribution, but that's a different matter.
Oh, alrighty then
Yes it doesn't force the developers to release the source. The other option is to remove their product from distribution.
So great point you have there.
On apps being subject to GPL
The issue would seem to be that apps link against bionic; therefore if bionic is GPL without linking exemption (which it could theoretically inherit from the alleged use of headers), then anything linking against it must be GPL. This doesn't happen on, say, Linux, because GNU libc is LGPL, not GPL.
The FSF has traditionally been keen on the idea that merely implementing an interface causes infection (as in the CLISP/readline case), but in practice most caselaw in commercial software seems to say the opposite.
it's a distasteful situation but a bad analysis
After 30min browsing through the affected headers I've not found anything that wouldn't be covered by the interoperability exception in copyright law. I doubt there's any macro in there that could actually be written another way unless the raw kernel headers are even worse than normal kernel coding (which ain't pretty). That's not to say the kernel devs couldn't deliberately introduce something like that though... ;)
Where the analysis goes badly wrong is in discussing UNIX as the context for there being many ways to write the same system macros or implementations. Which is true, *but this is a header for 1 specific UNIX implementation*, the available expressions of that interface are much more heavily constrained. It doesn't matter how a BSD or original UNIX implements non POSIX functionality, only the Linux version will work.
The licence change is distasteful but the reality is the choice of creating these headers manually would give them little more legal protection than they already have, there would still be 'copying' just done differently.
I doubt this will go further though, unless the Linux kernel guys want to see Linux vanish from Android rapidly, though Linus may take that position. With few native apps being written an overnight switch to BSD is a very real option, one with more clarity and less fudging of licence issues all round. Which would be a shame for Linux, the rest of us wouldn't notice any change.
kernel_headers != posix_headers || C_headers
/* Where's the kernel header in this program? */
/* First, a C library header: on GNU this is LGPL; on Bionic it's BSD (according to Wikipedia) .*/
/* Next some Posix headers; these are part of the library, and come with the same licence as the above. */
printf( "hello world; I am process %u\n", get_pid() );
/* Kernel headers are for things like ioctls, and it's perfectly possible to write a C program without ever using one. QED. */
So if you strip out the junk, the part that's left - the creative part - is then fair game? How odd! Maybe it should be patented.
Open Source is a mess, stick with closed source
At least with closed source you know the limits. None of this having to worry about whether you're supposed to supply source code etc. Why don't the open source mob simply remove all this GPL crap and just give stuff away left, right and center if they want to? If an open source developer wants credit or recognition, use copyrights and patents. None of this complexity needs to be.
You're kidding right???
Recently hit trouble with a plugin I was writing for a closed source app, basically I was expanding on some functionality within the application.
The proprietary license forbids reverse engineering, which was necessary for certain bits of my code, so on the face of it I had to stop development.
Less of an issue with Open source for obvious reasons.
"If an open source developer wants credit or recognition, use copyrights or patents"
Just WTF do you think the license is there to protect? If I just copyright my code, how are you supposed to know what I do and don't permit? The GPL is far more permissive than most proprietary licenses, but IMO is written more from a users point of view than a developers.
As for patents, are you really - with a straight face - suggesting that Software Patents are a good thing?? Have you not looked at the trouble they create, or are you just a grade A twat?
A/C cos I'm still toying with my code, at least until I can make a firm decision
I also see Apache as "more open"
Re: Gauntlet Set NOW!
From: Richard Stallman (firstname.lastname@example.org)
Date: Thu Jan 09 2003 - 02:28:47 EST
I'm not sure what your project is designed to do, so I don't have an
opinion about how it stands regarding the GPL. However, I've talked
with our lawyer about one specific issue that you raised: that of
using simple material from header files.
Someone recently made the claim that including a header file always
makes a derivative work.
That's not the FSF's view. Our view is that just using structure
definitions, typedefs, enumeration constants, macros with simple
bodies, etc., is NOT enough to make a derivative work. It would take
a substantial amount of code (coming from inline functions or macros
with substantial bodies) to do that.
Not the same thing.
He's talking about using #include not repurposing entire source files.
less open, but more free.
No app calls directly into the kernel, not even C apps.
C apps use the C runtime library. And that's licensed under the LGPL. Otherwise, each and every non-free app under Linux would violate the GPL. Linking an app with the C runtime, which them may call into the kernel, is completely fine.
FUD? Not so sure any more.
That was my thought (see post above). But apparently, Google have replaced the LGPL GNU C libraries with their own "Bionic" Library. And it's the creation of these headers that is disputed.
I don't have access to the files, so I can't see what's in them. (Would it be too much to ask a journalist to look...? ;-) Maybe when people say "kernel headers" they mean "scraped the LGPL libc headers". Or maybe Google *have* scraped some kernel headers - after all, many of the POSIX function calls will be wrappers round syscall(2).
Anyway, according to Florian Mueller's (rambling) post:
simply replacing Bionic with Libc is not an option. And if the standard headers really do containe GPL material, then there is a need for Google to sort it out.
are easy to find. I looked them up for you:
Ghost of SCO past
So to my ignroant self this seems somewhat like the machincations about copyright and errno.h in the SCO lawsuit:
Just a moment
IF the copyrights on the Unix header files were insufficient for SCO to claim that the linux ones infringed, how can the Linux folks now be trying the same thing on with google?
who said Linux folk raised this?
The Linux folk *aren't making this claim*. A pro Microsoft IP lawyer is, backed up lobbyist willing to take Microsoft money. Do you smell FUD yet?
Worse case overstated
Perhaps the Android headers are a derived work of the Linux kernel (as suggested by the automation of the Google's "cleansing" process). Perhaps the kernel header files required to compile a user space program are scenes a faire material. Doubtless it will take a court to decide.
But your worst case isn't legally likely. Lets say a kernel author sues a distributor of an Android app. That distributor would simply lodge a Motion to Dismiss stating the distributor was wholly reliant upon the statements and actions of Google in this matter and thus Google are the correct party to "provide satisfaction". This is a well understood area of copyright practice and well-founded motions are routinely granted (eg, when someone sues a cinema rather than the copyright holder of a film).
For example of the lack of ability of a distributor to provide satisfaction, imagine what will happen during discovery when the key question "how did you derive the header files from the kernel source" is asked of a app author. The answer will be "we undertook no such activity".
If Google is forced to relicense the header files under the GPLv2 then that won't apply retrospectively (simple equity argument about liabilities to third parties due to reliance upon fraudulent statements, again the now-fraudster Google would be the correct party to provide satisfaction). More likely would be a relicensing due to a settlement, and since the distributors are not a party to the settlement, no liability can fall to them.
Of course, a relicensing to GPLv2 will present a problem if app distributors wish to continue to sell their app after the relicensing but don't like the terms of the GPLv2.
Well thats interesting
The man who wrote the article has changed his on-line bio!
Whereas before he listed a lot of work done for (with) MS it now seems he has worked for
"Fortune 50 software company".
So we have the fact that using headers, correctly copyrighted or not, do not make your work derivative so no worries about being forced to reveal your code, and the fact the author of the work is trying to hide his association with MS creates a smell of FUD covered rats and is evidence of MS increasing fear of reality.
Pure FUD (however unintentional). Let's establish some facts:
1. Linus has stated that user-space code is not considered a "derivative work" of the kernel.
2. The rationale behind Bionic providing "clean" kernel headers makes no mention of the GPL.
3. The "clean" kernel headers are derivative works and must be re-licensed under the GPL.
4. The GPL does not force source code reveals.
Bionic simply needs to stop re-distributing the kernel headers with the package and use the kernel headers from the Linux source. Problem sorted, nothing to see here.
[4.] The choices are: Comply; Re-licence; or cease distribution of GPL portions.
Edward J. Naughton bio gets revised
[PJ: Edward J. Naughton, the attorney Huffington Post just published claiming Android may be in violation of the GPL has done work for Microsoft. Surprised much?
His article states this at the end: "The views expressed are my own individual views and should not be attributed to any clients." Nevertheless, at least one of them may be delighted.
His bio has changed recently. The link above is to its current state, where you will not find any mention of Microsoft. It's been changed to a "Fortune 50 software company". Here's what used to be on it, still in Google cache, a snapshot taken recently, on March 8]:
- Co-counsel defending Microsoft against a putative consumer class action alleging that it had violated wiretapping statutes and common law privacy rights by designing Windows to permit third parties to place cookies on computers. Obtained dismissal of complaint....
- Represented Microsoft in several dozen lawsuits against resellers and corporate end-users of counterfeit, infringing, and unlicensed software. - Brown Rudnick bio page for Naughton
What American IT lawyer hasn't done some work for Microsoft?
And how is this relevant to the fact that Google did re-appropriate some of the kernel code?
But thanks for adding you valuable input.
Re-appropriate kernel code in Android?
> What American IT lawyer hasn't done some work for Microsoft?
Remember when software companies wrote software, instead of hiring lawyers to spread IP litigation FUD about their competitors.
> And how is this relevant to the fact that Google did re-appropriate some of the kernel code?
Well according to this from Groklaw there isn't any re-appropriate kernel code in Android, a programmer might have actually spotted this.
“Do you know that there is not one bit of executable code in those files? They’re pretty much all macros and declarations forced by POSIX and other technical standards.”
> But thanks for adding you valuable input.
You're welcome ..
Zombie SCO FUD
Microsoft just release a phone and now we have Android FUD; there is no connection here at all.
Unless Android App developers decided to steal code, they have no issue with having to "show the code", apps compiled against the kernel header is compulsory for the Linux OS and is not a copyright violation at all.
Interesting regurgitation of The SCO Group speak" about header files and the magic number of the elves...
I give this FUD a fail.
This article is pure FUD. If it was printed on paper, I wouldn't even use it as toilet paper.
The notion that userspace apps that run on OS with a kernel created from GPL'd code must also be released under the GPL is complete rubish.
Particularly in the case of Android apps, which compile to a interpreted VM byte-code rather that linked against libraries and compiled to machine code. Something the author would know if they had an effing clue.
Android developers are no more "exposed" than any other developers of software that runs on an open source OS. Are Apple developers exposed to the BSD license because part of MacOSX is based on FreeBSD?
Google's shenanigans is "interesting", but in no way justifies the conclusion or headline.
The real question is Bill Ray being payed by MS, Apple, or both?
FUD to the Outside Lane Please
This article stinks of Microsoft FUD. Although it quotes several sources( probably planted by MS cronies) it fails to support the primary premise with anything more than innuendo. No, Android app programmers will not have to reveal their code! What a silly argument! But if you can look at the goal of the argument: programming on Android is bad for you - you can see the clear marks of unsubstantiated Fear, Uncertainty and Doubt by the FUD masters in Redmond. Really what better way to bolster windows phone 7 than to scare developers off the competition.
Quoting Linus Torvalds on the matter
You can check groklaw on the subject
which points to this one:
"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.
"The kernel headers contain various definitions for the interfaces to user space, and we even actively try to make sure that the headers can be used by user space (and try to mark which of the headers are expected to be usable in such a way). Exactly because we know user space needs those details in order to interact with the kernel.
"So I haven't looked at exactly what Google does with the kernel headers, but I can't see that they'd want to do anything fundamentally different from glibc in this respect," Torvalds wrote.
Torvalds seems to be at best bemused about the issue and perhaps a tad irritated.
"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.