I still find it incredible that after all this time, we still have all this trouble with writing up licenses that mean what we want.
Google's attempt to purge copyright from header files has put mobile developers at risk of being forced to reveal their own source code, according to legal experts. This time it's not patents or Android's reinterpretation of Java that's causing problems, but the Linux code that compiles down into Android itself. Google …
What do you mean "what we want"? Clearly the reasoning behind GPL'ing the Linux kernel makes sense and is for many the reason people commit code into Linux?
The whole idea of Linux is to keep ALL the derived code open, if companies were planning to do it with Android then though luck, welcome to the GPL ecosystem. Linksys, Tivo and others learnt how it works already.
If Google didn't like GPL they could have used one of the BSDs.
Actually, there isn't a problem writing a licence - the GPL is well understood (by those that don't have an agenda against it).
I find Google's approach *interesting*, and I can't help but think they've mad a whole pile of pain for themselves when they finally lose in court.
But as for the bit about applications developers having to reveal their code. **WHAT** ? Because the kernel and it's headers are under GPL doesn't mean that applications will have to be under GPL. That's one of the oldest bits if FUD thrown at free software and completely bogus. Now if the developer actually links some GPL code into their application then it would apply, but not just by writing an application that runs on that kernel.
"But as for the bit about applications developers having to reveal their code. **WHAT** ? Because the kernel and it's headers are under GPL doesn't mean that applications will have to be under GPL. That's one of the oldest bits if FUD thrown at free software and completely bogus."
Well put. Just because I #include <stdio.h>, doesn't mean that my code now falls under the GCC compiler GPL license. Bullocks! It would be the same as saying my Visual C# project is now copyright by Microsoft because I used their Visual C# lib headers. Utter BS.
The really sad thing? The author doesn't even know enough about the topic to address this in his article. Regurgitated FUD.
Firstly, please stop mixing things up yourself.
GCC is distributed under the GPL. stdio.h is from glibc, which is distributed under the LGPL. The LGPL allows you to link against glibc from proprietary code, GPL does not.
Then please read the original linked article, esp. pages 8 and 9, and address the specifics. In condensed form:
1) Google Bionic is linked against GPL'd kernel headers, therefore it should fall under the GPL.
2) "On Android, all native code must compile against Bionic", therefore all native applications fall under the GPL
Now point a flaw in that argument. Thankyou.
> 1) Google Bionic is linked against GPL'd kernel headers, therefore it should fall under the GPL.
Linus Torvalds disagrees with you. See http://www.itworld.com/open-source/140916/android-sued-microsoft-not-linux (down towards the bottom of that article). There are other quotations as well.
Richard Stallman also disagrees with you. See http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html .
> Now point a flaw in that argument.
The flaw is that you assume that use of content from the kernel headers necessarily constitutes a "derivative work" for the purposes of copyright law. This is incorrect; de minimis snippets and essential interoperability copying do not constitute derivation (or else it would be very difficult to use words like "the" and "and", as they are part of copyrighted works).
You're very welcome.
I was not making those assertions. The original article was.
*My* point was towards another poster, whose arguments were totally off the mark. I was hoping to get properly reasoned refutations of the original article. You provided those, including citations. So a sincere thank you for that.
Well the artical didn't mention applications. Where this could hit is with the custom OS versions used by some carriers, also the handset makers though i doubt most of them care much, Motorola springs to mind as one that could get somewhat pissed. If the carriers have to open their custom Os's i can see a lot of them droping Android and moving over to WP7. Which would then make Nokie look like geniuses!
> "I can't help but think they've mad a whole pile of pain for themselves when they finally lose in court."
Presuming they ever wind up in court for this. Very likely the copyright holders of the Linux kernel (Linus himself, others) will not care that much about the issue. It's not like they are Microsoft or Apple.
At most I guess the might use this as a lever to twist Google's arm into finally merging the Android kernel properly into the official Linux tree, something the kernel gurus have been complaining about for a long time.
Richard Stallman has long since proved that he's willing to pursue legal action against GPL violators, no matter how high or low profile they are. He probably wouldn't have the resources to win against Google, but he could certainly force concessions if the matter.
So, let me get this straight
You have a piece of copyrighted work, but if you remove something from it, it ceases to be copyright.
Does that mean I can rip music from CDs, pass them through an audio filter to remove something, say the content above 25KHz, thus removing the copyright and allowing me to distribute the work as my own.
And think of all those TV shows I can sell on - I just cut out the credits and flog them off as my own production.
I like it!
(mine's the one Andrew Crossley won't be chasing any time soon)
The header files may not be copyrightable in the first place.
Courts have determined before that you CAN NOT copyright an API. You can copyright the code that implements the API (unless the code to implement the API is to obvious) and you can copyright the comments surrounding the API but you can not copyright the actual API.
Which is all well and good except that courts have determined before that you CAN copyright an API (even if the code to implement the API is to obvious).
In other words the lawyers win and everyone else looses.
If you remove the copyrightable parts, what remains is not copyrightable. It's a tautology, so I'll explain. You take a song and remove from it the melody and lyric, the copyrightable portions (under US law), leaving a title or a chord progression, and the copyright holder has no ownership in what remains.
In code, some things are not copyrightable because, in my lay summary, it is what's necessary to do the job, for instance, a for loop, an if-then-else, or, variable assignment. However all those non-copyrightable elements in the aggregate from an implementation of functionality, and the more complex a function, the less one may say this was the one way to do this in defense of programming by copy and paste.
Comments are not necessary, so the copyright holder does own those.
The script, the music, the fixing of the performances in a tangible media, all those are copyrightable and the holder retains copyright after you strip off the credits. (Are credits copyrightable? A lot of movies start and stop the same way.) Well, back to the drawing board, won't get rich today.
> (mine's the one Andrew Crossley won't be chasing any time soon)
Don't think he'll be chasing anyone, ever...
Bet he's not so worried about his train these days either...
Yes, the remarkably authentic looking German one, ta.
As much as I would like very much for all Android apps to be free and open source, I think everyone should understand with crystal clarity what it is they're gettinginto and who they owe their business sucess to.
The header removal isn't just offensive, it's impetulant. Google, stop it before something bad happens.
In the article you imply that, without explaining how, an Android 3rd party developer may be forced to publish the source code to their application simply because it runs on Android. I call an analysis fail on this claim.
In simplistic terms if this were true, every piece of commercial software currently running on top of a GPL v2 licensed OS would also have to be open sourced. I think somebody would have spotted this issue before now.
Just because application 'A' uses an API in operating system 'B' does not make it a derivative work. Only when application 'A' includes copied/modified source code from operating system 'B' is the developer forced to open source his or her application because it is in part derived from the GPL'd source code.
I fail to see how a possible transgression by Google can cascade down onto application developers that have developed on top of Android, so suggesting that Android developers will be forced to publish source code is highly misleading and FUD to boot.
If Android is contaminated, than anything that uses the Android headers are contaminated ALSO, according to the GPL's pervasive licensing terms (which state in a nutshell, if you use GPL code, your code becomes GPL also, and any code that uses your code becomes GPL because of that). And since you basically need Android headers to build an Android app...
The key paragraph is at the bottom of page 8 and indeed acknowledges the very point I made. Java code destined to run under Android neither links to, nor includes, the Kernel headers at the heart of the dispute. Therefore they cannot be implicated in any violation of GPL v2. It's a shame that Brown Rudnick don't clarify this point but then they probably don't appreciate the subtlety.
The people who are at risk are those who have forked Android such as Cyanogen(mod), and those who are writing native C/C++ code that does link against / include the kernel headers.
But you can still write native code that does not fall foul of the licence. I repeat my assertion that this only affects third parties in a very limited sense. For most of us it's business as usual.
>>"In the article you imply that, without explaining how, an Android 3rd party developer may be forced to publish the source code to their application simply because it runs on Android. I call an analysis fail on this claim."
It's not "simply because it runs on Android," but simply because some of those applications were compiled using the headers which are potentially protected under the GPLv2, making them derivative works by extension.
I agree with you but ONLY in the situation that the application in question has actually incorporated the GPL'd code into its own distribution. I write Java, compile it to Dalvik, and distribute an APK file. I've not so much as even glanced at the Kernel headers so my code is not GLP'd by contamination.
The number of end-user applications that will need to reference the kernel headers is probably so close to zero as makes no difference. You've got to either compile in at least one GPL'd file into your application, or copy and paste code from at least one GPL'd file, to be affected at all. And for people writing in Java for Android it just isn't possible. For people writing in C/C++ for Android it's still highly unlikely to be an issue.
FUD FUD FUD plain and simple. Learn your license terms and understand what you need to be doing with/to open source for them to affect you.
We're not talking about Java applications compiled to Dalvik, but native applications using the Bionic C library. The Bionic library is derived from the Linux kernel header files, and the allegation is that *those* kernel header files were copyrighted and distributed under the GPLv2 license.
Linux includes a cleansed library derived from the kernel header files for user-land applications. This library is free to use, not bound by the GPLv2, and only contains constant, variable, and data structure, and other declarations.
However, Google decided not to use this library, but to go back to the original source, the raw kernel header files. Those contain a rather large amount of in-line functions and macros, and those *are* distributed under the GPLv2. Thus by implication, Bionic should be subject to the GPLv2 as well--or so the argument goes.
If the allegations are correct then, *any* application--including Android itself--that includes Bionic headers when compiling, _is_also_ subject to the GPLv2 license. Take a look at this analysis for an explanation of what is being argued here:
You don't really know what you're talking about, so I would suggest you read up on licences, not just the ones you think apply to you. GPL doesn't apply only when compiling in files, linking to them is enough.
And a great number of applications link with the Google C library which includes the kernel headers. This is not just for applications that call the special kernel functions.
So In this case it's better to have some FUD that be FUcked.
> GPL doesn't apply only when compiling in files, linking to them is enough.
True, but irrelevant to the rest of your post.
> a great number of applications link with the Google C library which includes the kernel headers.
If Google were using the GNU libc, the licence would be LGPL, not GPL. You can link against an LGPL library without your code becoming covered by either GPL or LGPL.
However, Google are not using the GNU libc. They're using a BSD-derived libc. That is not GPL...
> So In this case it's better to have some FUD that be FUcked.
I'm not sure I would agree with you there - but it is certainly better not to have to deal with the FUD at all. That's achieved by reading the licences, rather than just making rash statements about them.
Is that you're wrong.
How is my answer irrelevant when it's correcting a misunderstanding of the OP?
Also Google is not using a BSD derived libc, it's derived from from BSD and GPL, - with GPL being the more infectious - and licensed under Apache.
The FUD here is because even if you read the licences there's always a margin for legal interpretation. But better be safe than sorry, as they say.
But don't let this stop you from making rash statements about what others say.
> How is my answer irrelevant when it's correcting a misunderstanding of the OP?
Because it does no such thing.
The poster to whom you replied was telling you why his code is not covered by the GPL. So your attempt to tell him about why the GPL covers derivative works is irrelevant - because his work is not a derivative of the GPL. That's what he was saying...
> Also Google is not using a BSD derived libc,
Well, it is.
Some guy with links to Microsoft has recently claimed that it contains GPL code - I've yet to see any of the copyright owners making similar claims. If any do, then there might be a case to answer. But until and unless that situation occurs, there is nothing to write about here; it's simply FUD.
> The FUD here is because even if you read the licences there's always
> a margin for legal interpretation.
No there is not. The licences are clear.
The complications arise because ACs on the Internet make sweeping statements about what the licences say without actually reading and understanding them.
> But don't let this stop you from making rash statements about what others say.
Pot, kettle, ..
 Even if there is some verbatim copying from the Linux headers, that does not necessarily mean any violation of copyright has occurred; some things are not protectable by copyright. Exactly that argument bit SCO in the arse when they tried to claim that Linux was a derivative of Unix because it used the same values in errno.h.
Google probably didn't care, after all the app store, like apples, is there to encourage people to buy phones, with of course Android as the OS. Basicaly google would prefere that most apps were free and the developers relied on adds to make money and if the App is free, who cares if it is GPL. Ok, the developers may care but their not googles product or customers.
What interesting is that based on how I understand copyright (I am not a lawyer), I could thoroughly review someone's GPL code, figure out how it works, then turn around and use the same concepts to write a piece of software that does the same thing and whose code is nearly identical. If the software were patented, then they could lay claim to the *process*, but copyright protects *content*, not *concept*, so unless I actually copied their code, even though my code accomplishes the exact same thing, using the exact same concepts, it's my code not their code, and copyright wouldn't seem to apply.
But as I said, I am not a lawyer.
You are basically correct - you can write your own piece of software that does essentially the same as another piece and it won't breach their copyright. However doing it in the way you describe is risky since you will likely remembers details of how the other program did it and so include bits of the code. There is the risk that what you end up with has enough similarities to keep the lawyers fed for a while.
That's why outfits wanting to do such things typically employ "clean room" techniques. For example, they may simply not employ any programmer that has ever worked on or been involved in any way with the project they are working on - and documenting all the steps they took to avoid any code contamination. This was certainly reported to have been done in the early days of "IBM PC compatibles" so as to produce a BIOS that IBM couldn't complain about and thus open up the clone market. The only knowledge to go in would be the details of **what** the code was to do (ie implement the published APIs) - what had to be proven to be absent was any input as to **how** anyone else had implemented it.
It's also why, in the Microsoft settlement with the EU, it is expressly recognised in the settlement document that independent coders may arrive at similar code when implementing a specific function - and that such similarities don't amount to code theft or copyright infringement. Without such language, there would be a real of of a free software project (such as Samba) implementing a compatible function and MS killing them with false copyright infringement claims.
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)
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.
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.?
"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.
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.
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.
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.
"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.
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.
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.
/* 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. */
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.
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
Re: Gauntlet Set NOW!
From: Richard Stallman (email@example.com)
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.
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.
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.
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.
[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?
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 ..
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?
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.
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.
Biting the hand that feeds IT © 1998–2019