Google copyright purge leaves Android developers exposed 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).
> Thankyou.
You're very welcome.
Vic.
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...
http://www.bbc.co.uk/news/technology-12767714
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.
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.
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.
This post has been deleted by its author
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.
This post has been deleted by its author
>>"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.
-dZ.
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:
http://www.brownrudnick.com/nr/pdf/alerts/Brown%20Rudnick%20Advisory%20The%20Bionic%20Library-Did%20Google%20Work%20Around%20The%20GPL.pdf
-dZ.
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.
Vic.
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[1]. 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, ..
Vic.
[1] 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.
This post has been deleted by its author
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
